うさぎでもわかる

Shell Script

2021-01-24T14:36:47.740000Z

Shell Script をキチンとやろうと思って色々さわったので備忘録メモです。

独学プログラマーのPart3 (第16章 Bash, 第17章正規表現) を読む

Bash (オプション_コラム)

$ ls --author -l    # Ubuntu

--author オプション初めて使ったかも。ls の help を見たら -A とのこと。なるほど〜

$ ls --help    # Ubuntu
Usage: ls [OPTION]... [FILE]...
List information about the FILEs (the current directory by default).
Sort entries alphabetically if none of -cftuvSUX nor --sort is specified.


Mandatory arguments to long options are mandatory for short options too.
  -a, --all                  do not ignore entries starting with .
  -A, --almost-all           do not list implied . and ..
      --author               with -l, print the author of each file
(略)

macOS では --author オプションが存在しなかった(;_;)

ただ -author オプションであれば動作するのだけれど、これは -a, -u, -t, -h, -o, -r を同時に指定したコマンドというだけで Ubuntu 上の --author とは別物らしい。(そりゃそうか) ほえ〜〜

$ ls -author -l    # macOS

正規表現

口ではなんとでも言える。コードを見せなさい。ーーリーナス・トーバルズ

き、厳しい〜〜

正規表現に自信のないわたしにはグサグサ刺さった上に、何も言えない気持ちになりました・・

$ python3 -c "import this" > zen.txt
$ cat zen.txt 
The Zen of Python, by Tim Peters


Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

grep の練習用として使うテキスト(Tim Peters の詩)が詩人だなぁと思ったので載せました。

$ grep Beautiful zen.txt 
Beautiful is better than ugly.


$ grep -i beautiful zen.txt    # -i は大文字小文字の違いを無視
Beautiful is better than ugly.


$ grep -o Beautiful zen.txt    # -o は一致した単語のみ抽出
Beautiful


$ grep ^If zen.txt    # キャレット記号(^)は行の先端に一致するものを表示
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.


$ grep idea. zen.txt    # ピリオド(.)は xx. の xx の後ろに何がきても一致する
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!


$ grep im. zen.txt
The Zen of Python, by Tim Peters
Explicit is better than implicit.
Simple is better than complex.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.


$ grep idea.$ zen.txt    # ドル記号($)は行の終端に一致するパターン
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.


$ grep im.$ zen.txt    # 何も表示されない


$ grep implicit.$ zen.txt    # implicit. で終わる行が表示される
Explicit is better than implicit.

複数文字との一致

$ echo Two too. | grep -i t[wo]o

Two too.

$ echo Two too twoo. | grep -i t[wo]o

Two too twoo.

$ echo Two too twoo towo. | grep -i t[wo]o

Two too twoo towo.

↑一致する部分を赤く表示

[abc] は a, b, c のどれか1文字に一致する。

つまり t[wo]o はt で始まり、その次に o か w の文字がきて、次に o がくる ということ。

※ macOS(zsh) では再現されず。Ubuntu で実行しました。

数値との一致

$ echo 123 hi 34 hello. | grep [[:digit:]]

123 hi 34 hello.

$ echo 123 hi 34 hello. | grep -o [[:digit:]]

繰り返し

$ echo tw two twoo twooo not too. | grep two*

tw two twoo twooo not too.

「直前のパターンが0回以上一致」

two* であれば tw という文字のあとに0回以上のoが続く文字列に一致する ということ。

$ echo _hello_there | grep -o _.*_

_hello_

ピリオド(.)は、どんな文字にも一致する。

アスタリスク(*)と組み合わせることで、どんな文字列にも一致する。

このアスタリスクは貪欲なので、できるだけ長い文字列に一致する。

$ echo _hi_bye_hi_there | grep -o _.*_

_hi_bye_hi_

エスケープ

$ echo I love $ | grep $

I love $

$ echo I love $ | grep \\$

I love $

特殊な文字をエスケープして本来の文字に一致させたい場合、文字の前にバックスラッシュ(\)をつける。

シェルスクリプト練習問題（入門編）について

後日やる

シェルスクリプト練習問題（中級編）について

MEMO

one-tab

Kubernetes Middle Way

2021-01-28T00:46:44.788000Z

Kubernetes Middle Way の最終セッションの内容が良さげだったのでまとめました！

https://www.youtube.com/watch?v=KmM16GHwies&feature=youtu.be

スライド資料

整理しながら理解する、Kubernetesのネットワークの仕組み by @hhiroshell

1. イントロダクション

Kubernetes のネットワークはいろいろな用語が出てきて把握が難しい

このセッションのゴール

Kubernetes のネットワークの全体像を理解する
様々な構成要素の役割と関係性を整理して把握
ネットワーク周りのドキュメントの言っていることがわかる

2. Kubernetes のネットワークのアーキテクチャ

全体を4つに分けて考えてみる

Node Network

インフラによって実態は異なる

ベアメタルなど。なんだろうベアメタルって・・🤔🐻くま？
Pod Network / Cluster Network

Node Network 上にソフトウェア的に構成される論理ネットワーク

要件がいろいろとあるらしい

クラスター内の全 Pod が、互いのIPアドレスでNATなしで変換できるなど
kubelet と CNI プラグイン

Pod を Cluster 内のネットワークに参加させる

kubelet が Pod を起動するときに CNI プラグインを実行することで上記を行っている
Service Network

Pod に対する通信において、名前解決・ロードバランシング・サービスディスカバリなどの機能を提供する

3. Cluster Network

公式ドキュメントでは"Cluster Networking"。自力構築する場合は Flannel, Calico などを使う

Flannel って？

https://kubernetes.io/ja/docs/concepts/cluster-administration/networking/#flannel

’’ Flannel is a very simple overlay network that satisfies the Kubernetes requirements. Many people have reported success with Flannel and Kubernetes. (Flannelは、Kubernetesの要件を満たす非常にシンプルなオーバーレイネットワークです。多くの人がFlannelとKubernetesで成功したと報告しています。)

ほえー！

Linux Bridge と VXLAN によるカプセル化を組み合わせて、Node をまたぐ通信を抽象化

VXLAN によるカプセル化とは: Flannel のデーモンプロセスによって、宛先の Pod が起動している Node 宛てとなるようにヘッダを追加する→スライドp20〜24の図が分かりやすかった！✨192.168.2.2を、192.168.254.12が包んでいる(カプセル化している)。

【参考】

シナリオ: Linux Bridge を使った基本構成

https://docs.openstack.org/liberty/ja/networking-guide/scenario-classic-lb.html
project-calico

https://kubernetes.io/ja/docs/concepts/cluster-administration/networking/#project-calico

’’ Project Calico is an open source container networking provider and network policy engine. (Project Calicoは、オープンソースのコンテナネットワーキングプロバイダーおよびネットワークポリシーエンジンです。)

4. kubelet と CNI プラグイン

kubelet

Pod を起動/停止する処理

CNI プラグインを実行する
CNI プラグイン

Container Network Interface (CNI) 要件を満たす実装

Pod をネットワークに参加させるのに必要な処理を実行 (kubeletからそれを呼び出す)

flannel であれば flannel plugin

NIC に IPアドレスを割り当てる

5. Service Network

Service リソースによって以下のことが起きる

Service に対応するIPアドレスの払い出し
Service の IPアドレスに対して、ホスト名の割り当て＆クラスター内に DNSレコードが登録される
Service に対するアクセスが Pods に対してロード・バランスされる
配送先の追加、除外が自動的に行われる

内部では

kube-proxy が Service (API サーバーにある)を見る→ Service の記述内容に合わせて Node 上の iptables を更新する

※ Proxy mode には v1.1 までのデフォルトである userspace プロキシモード、v1.2+ のデフォルトである iptables プロキシモード、ipvs プロキシモードなどがある。

[Servce].[Namespace].svc.cluster.local.

.svc.cluster.local. 部分は省略可能だが、パフォーマンスの観点では完全修飾名を指定するのが良いとのこと。

クラスター外からの通信の受け入れ

Service

Type: NodePort
Type: LoadBalancer

Ingress

↑このあたりは検証で構築したの出来てる？って見るときに使ったぞい\\٩( 'ω' )و //

🌼 所感 🌼

用語と全体の動きをザックリと把握するのに良い資料だなぁと思いました。

Flannel や、内部の VXLAN によるカプセル化について図で納得できたのは収穫でした！

purpose of the week

2021-01-24T11:47:28.504000Z

タイトルが英語なのは、Markdown化 (Hugoへ移植) するときスムーズにするためです。。

画像がうさぎなのは、単純にうさぎが好きだから＆まだまだ出来なくても成長するぞ！の心意気です。成長を実感したら、もう少し大人なうさぎにするかも。

体力づくり

体力づくりは習慣化まあまあ出来ていて

毎日お風呂後にストレッチ
週に5回くらいストレッチ後に筋トレ(腹筋＆背筋それぞれ50回ずつ)
週2〜3回の朝ランキング

↑これが、来月まで続けば御の字かなぁ。

続けられなくても、代替策を考えればOKの気持ちで💪

学習面は、書かないとやらないな？と思ったので書きます。

技術

Kubernetes Middle Way

勉強会の内容、発表動画と資料を参考にまとめる

youtube発表動画

スライド資料
shell script

シェルスクリプト練習問題（中級編） | ゆるっとエンジニアブログ

独学プログラマー(Part3)
SQL

独学プログラマー(Part4)
Python

独学プログラマー(Part1,2)

それぞれ完了したらアウトプットするぞい。

語学

TEDシャドーイング

How language shapes the way we think | Lera Boroditsky (youtube)

言語の違いが考え方にどう影響するのか具体例をもとに紹介されている。おもしろい〜
Linux Today 翻訳

ラズパイの新作にテンアゲしたので。

Raspberry Foundation Release Their Own Silicon, the Raspberry Pi Pico

Evernote blog

2021-01-24T12:02:57.023000Z

今日から試験的にEvernoteでblogを書いてみたいと思います。

今までHugo+Netlifyで3ヶ月ほどblogを運用していましたが、Postach.io というEvernoteのノートブックをそのままブログにできるサービスがあることを知って、思うところもあり乗り換えてみようと考えました。

✾ Hugo+Netlify から Evernote+Postach.io へ乗り換えようと考えた理由

1) HugoはThemeカスタマイズが手間

GitHub上などで公開されているThemeを読み込んで簡単に変更できますが、それらをカスタマイズするにはリポジトリをフォークして、cssファイルなどを上書きする必要があります。(ちょっと面倒くさい)

2) git管理が煩わしい

静的サイトジェネレーターは更新の度にgit pushするのが手間なうえ、書き直したエモい差分がGitHub上で公開されてしまうなどの問題があります。(これはプライベートリポジトリで管理してしまえば解決します。)

3) Markdownでは細やかな色付けが難しい

カスタマイズすることで不可能ではないですが、基本的にモノクロで少しさびしいです。

4) WYSIWYGエディタマイブームが来ている

GitHub上でオープンソースのWYSIWYGエディタを探したり、「編集作業とは」について考えることが増えたり、人生で初のWYSIWYGブームが到来中です。

5) Evernote to Markdown のGitHubリポジトリを見つけた

*.enex形式でエクスポートされたEvernoteを、Markdownファイルに変換するCLIツールを見つけました。いつでもHugoに戻ってこれるね♪

Wordpress to Markdownの際も画像の移行で詰まったけれど、たぶんEvernote to Markdownも画像なり日本語のファイル名なりでエラーしそうな予感がしています。

Wordpress on EC2 から Hugo+Netlify に乗り換えてから、すっかりblogの更新が減ってしまった。

正直、Hugoを触っていて一番テンションが上がった瞬間って、Wordpress からエクスポートしてきた記事をCLIツールでMarkdownに変換して、それをHugoで問題なく表示できた瞬間がピークでした。

更新するために、わたしにとって大事なのは書いていてテンションがあがるツールなのでは？という思いがフツフツと湧いてきたのが大きかったです。

乗り換える決め手となったのが Evernote to Markdown のGitHubリポジトリを見つけた なので、まぁいずれHugoかGit管理でのBlogに戻るでしょうというツンデレ記事な部分はあります。Blog書くだけで草生えるしね。

p.s.

個人的にHugoのThemeで Github-Style というのが可愛くて良いなぁと思ったのだけれども、Themeのリポジトリが維持管理されている前提があってこそであって、バグ修正のしやすさを考えると手の込んだThemeは敬遠してしまう〜

MEMO

救済措置用

・Evernote to Markdown

https://n350071.com/release-enex-to-markdown/

https://github.com/wormi4ok/evernote2md

https://github.com/n350071/enex-to-markdown

test①

2021-01-17T12:37:36.275000Z