Docker勉強会
Your SlideShare is downloading.
×
Check these out next
More Related Content
Slideshows for you (20)
Similar to ssmjp 20210810 nlog2n2tejun pw (20)
More from Sekiguchi Toshihiro (7)
Recently uploaded (20)
ssmjp 20210810 nlog2n2tejun pw
- 1. @nlog2n2 Sekiguchi Toshihiro 手順書の書き方LT お前らの手順書の書き方は間違えている ディレクターズカット版
- 2. パワーシェルのおすすめ書籍 • いくつか読みましたが、これが一番だと思います。 何でもできるパワーシェルは人類にとっては早すぎます。
- 3. 自己紹介 • Twitter：nlog2n2 • 名前：Sekiguchi Toshihiro(椹口敏広） • 学歴・職歴 • 神戸高専、豊橋技術科学大学・大学院 • ISP、メーカー、SIer、ベンチャーx2 など • 自称フリーランスなのでお仕事ください（new）
- 4. 今日話すこと 手順書の書き方について書こうとしたら、 オペレーションのお作法みたいになったでござる。
- 5. 質問です
- 6. 手順書、何で書いてますか？ 30 56 53 8 https://www.menti.com/tr3nsuipzn
- 7. https://www.mentimeter.com/s/e2a20547b1c338a4d35725821ac3234e/a2e36790d586 アンケート結果 圧倒的O ffi ce
- 8. 手順書の作成ツールについて • 手順書を書くツール遍歴 • YAML とバージョン管理システム • Microsoft o ffi ce • AsciiDoc • Markdown＆ShellScript 個人的には、「ドキュメントシステムはこれを使え2015版」が良い資料だと感じました。 https://www.slideshare.net/k16shikano/2015-55455604
- 9. 各ツールの特徴 • マイクロソフトオフィス製品 • 変更内容が追い難い。差分が取れないのでメンテナンスがしずらい。 • ファイル名のどれを信用すればいいかわからない。 日付、最新版、New、OLDなどでファイル名が乱立してよくわからない。 • 他社や他部門の人間と連携が取りやすい。 • 変数など動的に値が変わるものに関して、ヒューマンエラーが発生しやすい。 • マークアップ言語＆バージョン管理システム（Subversion, Github等） • 変更履歴が追いやすい。誰がいつ変更したか分かる。 • 画像が挿入し難い。ネットワーク図がアスキーアートなどになると複雑な絵を要求される。 • ラフな手順書は書けない。 • 他社との連携が取りずらい。 • Pandocであらゆるフォーマットへ変換し放題になる。 • タグ付けしてコンフィグ等と同じところにコミットすることで、時系列に手順書が保存できる。
- 10. 1. よくもらう手順
- 11. 1. アプリケーション部門からよくもらう手順書 tar -zxvf 20211231.tar.gz cd 20211231 ./bin/release.sh cat ./log/release.log( successと出てたらOK）
- 12. 1. アプリケーション部門からよくもらう手順書 こんな手順書が仮にあったとしましょう。 どのあたりが問題だと思いますか？ tar -zxvf 20211231.tar.gz cd 20211231 ./bin/release.sh cat ./log/release.log( successと出てたらOK）
- 13. 1. アプリケーション部門からよくもらう手順書 こんな手順書が仮にあったとしましょう。 どのあたりが問題だと思いますか？ → 取り急ぎ、右側の内容が頭によぎる tar -zxvf 20211231.tar.gz cd 20211231 ./bin/release.sh cat ./log/release.log( successと出てたらOK） 左側の手順書の良くないところ • ログイン元の端末情報が存在しない • ログイン先の端末情報が存在しない • 20211231.tar.gz の説明が存在しない • どのユーザーでログインするか指定されていない • どのディレクトリで実施するか指定されていない • ./bin/release.sh の内容を引継を行なっていない • ./bin/release.sh の実行ユーザーが誰か分からない • log に success って、過去のものと今回の物を分別 する方法が記載されていない • サービスの確認がログのみになっている • 疎通確認、サービス確認、稼働しているポートの確認 などが存在しない • コンテナの中で実行している可能性もあるが、どこで 実施する作業なのか記載されていない • 冗長系なら片系落としながら作業なのかも不明
- 14. 2. 修正
- 15. 2. 修正 0. 前提情報及び作業環境へのログイン • 作業は、踏み台サーバを経由して、本番のサーバで実施する。 • 作業者の作業端末を使い ssh でログインを行う。 • 事前作業で /var/ssmjp/src の配下に 20211231.tar.gz のファイルを置いている。 • 20211231.tar.gz の中には、Webサイトの証明書、軽微な不具合修正を行なったソースコードがあ り、./bin/release.sh を実行することでリリースされる。修正内容は、Github の XXXX を参照。 • リリース作業は ssmjp-ope のユーザでシェルを実行する。パスワード等はユーザ管理表を参照。 0.1 本番サーバへのログイン $ ssh -A -p XXXX ec2-user@step.ssmjp.ad.jp $ ssh -A -p XXXX ec2-user@ssmjp.ad.jp 0.2 作業環境の確認 $ hostname * ssmjp.ad.jp と表示されること $ pwd * /home/ec2-user と表示されること $ cd /var/ssmjp/src $ ls -ltr ¦ grep "20211231.tar.gz" 1. リリース作業の開始 1.1 左側の手順書の良くないところ • ログイン元の端末情報が存在しない • ログイン先の端末情報が存在しない • 20211231.tar.gz の説明が存在しない • どのユーザーでログインするか指定されていない • どのディレクトリで実施するか指定されていない • ./bin/release.sh の内容を引継を行なっていない • ./bin/release.sh の実行ユーザーが誰か分からない • log に success って、過去のものと今回の物を分別 する方法が記載されていない • サービスの確認がログのみになっている • 疎通確認、サービス確認、稼働しているポートの確認 などが存在しない • コンテナの中で実行している可能性もあるが、どこで 実施する作業なのか記載されていない • 冗長系なら片系落としながら作業なのかも不明
- 16. ツッコミが間に合わん！！！ と言うわけで、こう書けや！とうい内容をまとめていく。
- 17. 3.手順書を書くときの基本方針
- 18. 3.手順書を書くときの基本方針 1. 作業ログを残す準備をしよう 2. 日本語はしっかり書く 3. 作業内容を共有できる項番をつける 4. history コマンド打てば、どこで何をしたか分かるように書く history コマンドは考古学
- 19. 3.1 作業ログを残す準備をしよう Mac OS（標準のターミナル) script コマンド、tee コマンドを使ってログを残す。 script コマンドだと、ターミナルの起動時のサイズで行数、列数が設定されてしま うみたい。制御文字も入るので可読性に難あり。less -r しがち。 Mac OS（ +Shift+5 で録画） MacOSの標準機能で付いている録画機能。標準の録画ファイルは重たいので FFmpeg コマンドで mp4 に変換して NAS に保存する。手順書を残す時間的な余 裕がないときに使う。 Windows Teraterm にログ設定をすると良い。ログファイル名はカスタマイズが可能なの で、ホスト名_YYYYmmdd_HHMMSS.log とかにするのがお勧め。
- 20. 3.2 日本語で作業内容を書く 検証環境で手順の検証が終わったら、オペレーションの内容をできるだけ詳細 に日本語で書きましょう。メンテナンス計画書、メンテナンス手順書の2つが あることが望ましい状態です。 メンテナンス計画書 (技術的なことは書かない) 通し番号、タイトル、日時、担当者、レビュー担当者、作業目的、作業内 容、メンテナンスアナウンス、影響範囲等 メンテナンス手順書 (技術的なことも書く) メンテナンス計画書の通し番号、構成管理上の参考資料の場所、事前作業、 本番作業、切り戻し手順、事後作業
- 21. 3.2 日本語で作業内容を書く メンテナンス手順書 事前作業、本番作業、切り戻し手順、事後作業に関しては、以下のフォーマットで書くようにして います。色が使えるなら色を使いましょう。 1. 本番作業 1.1 作業タイトル 1.1.1 作業内容 作業内容に関する説明書き コマンド1 コマンド2 コマンド3 ＊確認コマンドと予想される結果 1.2 作業タイトル（続く）
- 22. 3.3 作業内容を共有できる項番をつける 各作業に番号をつけましょう。 どこの作業をしているのか、他者に共有しやすくなります。 Slack でメンテナンスの状況報告 メンテナンスの事前レビュー メンテナンス失敗時の事後報告 番号をつける副次的な効果として、手順書がそれっぽく見えます。
- 23. 3.4 どこで何をしたか分かるように書く 3.4.1 誰がどこにログインするか書こう 3.4.2 絶対パスで書く 3.4.3 ユーザー、権限周りは事前に確認する 3.4.4 前後の確認は awk, grep, di ff を有効に使う 3.4.5 ダイイングメッセージ性のあるコマンドを使う 3.4.6 手順書を作るシェルを書く
- 24. 3.4.1 誰がどこにログインするか書こう ログイン（ログオン）するための情報を書きましょう。 IPアドレス（ホスト名、IPアドレス、IPv6アドレス） プロトコル（telnet、SSH、RDP、etc...) ポート番号 ユーザー名、パスワード ログインするためのアプリケーション（terminal、RDP、teraterm、etc) 間違った端末でオペレーションしないように、ログイン後、hostname , pwd コマンドでオペレーションの場所を確認することをお勧めします。
- 25. 3.4.2 絶対パスで書く 操作するファイル、ディレクトリの指定を絶対パスにすることで、history の前 後のコマンドに依存せず、何の作業したか理解がしやすくなります。 cd, cp, touch, mkdir などでパスを指定するときは絶対パス rm -rf とかついうっかり "rm -rf /" とかしちゃうとアレでアレでアレ 例外的に、シェルスクリプト、Python、Ruby、Perl などのプログラムの 実行に関しては相対パスで手順を作成する
- 26. 3.4.3 ユーザー、権限周りは事前に確認する 何かと検証環境では、sudo su で root ユーザーになりがち。 事前作業や構成管理の段階で、パーミッションの確認をした上で手順書を書きま しょう。 ls -ltr ¦ grep "<対象の絶対パス>" で権限を確認し、手順書へ反映します。 手順書のコマンドの行頭に＄＃を手順書内に書たりします。 必要に応じて、シェルスクリプトには chmod +x XXX.sh とかしましょう。 特に手順でシェルを実行するコマンドの場合は、事前に本番環境のユーザー・グ ループ・パーミッションすべて確認しておく方が無難です。
- 27. 3.4.4 前後の確認は awk, grep, diff を有効に使う 作業後の効果確認には、cat, di ff , grep -o, awk -F "区切り文字" '{print $X}' などで、変更の確認するのがベター。 よほど複雑じゃない限り、目grep でも良い気がする
- 28. 3.4.5 ダイイングメッセージ性のあるコマンドを使う Vim, Emacs, Nano 戦争に終止符を打とう エディタで開いて設定ファイルなどを編集すると、history しても、何をどのように変更し たか分からなくなる。 基本的には sed, echo, touchなどにリダイレクト繋げて、コマンドにして手順書を書く。 docker コンテナの中の操作も１行のコマンドで行うようにしました。 インフラ設計として、ホストのディレクトリをマウントする設計に変えた方が良い気がして いますが、本番で動いているものを変更するのは難しいので、運用でカバー。 $ docker exec -it web cat /etc/nginx/nginx.conf ¦ grep "worker_processes" worker_processes 1; $
- 29. 3.4.5 （例）crontab の編集作業 1. ログ取得定時実行停止 1.1 crontab の状態の確認 $ crontab -l ¦ grep "^*/10.*work.sh$" □*/10 * * * * ./home/vagrant/work.sh と表示されること 1.2 crontab コマンドでバックアップの取得 $ crontab -l > crontab $ cat crontab 1.3 ログ取得シェルのコメントアウト $ sed -i.bak -e 's/^/#/' crontab 1.4 差分の確認 $ di ff crontab crontab.bak □以下の内容が表示されること 1c1 < #*/10 * * * * ./home/vagrant/work.sh --- > */10 * * * * ./home/vagrant/work.sh 1.5 crontab への適用 $ crontab crontab 1.6 crontab の状態の確認 $ crontab -l ¦ grep "^#*/10.*work.sh$" □ #*/10 * * * * ./home/vagrant/work.sh と表示されること 1.7 一時的なファイルの削除 $ rm -i crontab*
- 30. 3.4.6 手順書を作るシェルを書く 定型作業に近い状態であれば、他人が手順書を同じように書くのは不可能か つ非効率なので、シェルスクリプトで手順書が出力されるように書く。 前職、同僚のロシア人に入力を、ハードコーディングしないで、変数の入力 は、インタラクティブにした方がいいよと指南された。いいマサカリ。
- 31. Tips
- 32. Tips1: よく使うショートカットキー • Linux • ctrl + l 画面をきれいにする • ctrl + r コマンドの履歴を出す（ctrl + n , ctrl + p ) • ctrl + a 行頭へ移動 • ctrl + e 行末へ移動 • ctrl + c プロセスを強制終了させる • Windows • Windows キー + R でファイル名を指定して実行を起動 • control 入力 コントロールパネル起動 • mstsc 入力 リモートデスクトップ起動 • cmd 入力 コマンドプロンプト起動
- 33. Tips2: 積極的に使っていきたいショートカットキー • Linux（bind -p で一覧が表示されるらしい。ほんまか？） • ctrl + u カーソル位置から行頭まで削除 • ctrl + k カーソル位置から行末まで削除 • ctrl + w カーソル位置の単語を削除 • ctrl + y 直前に削除した文字列を貼り付け • ctrl + z 処理を一時中断 • esc + f 一単語前へ移動 • esc + b 一単語後ろへ移動
- 34. Tips3: 良く使うコマンド sed , touch , echo にリダイレクト( > とか >> ) 闇に放り込む（/dev/null） 順番に並べて、値をまとめて、さらに順番に並べる( sort ¦ uniq ¦ sort ) bash で for 文で数値演算してたら awk に書き換える 最近知ったけど nohup XXXX & で ssh セッション切れてもバックグラウンドで実行（バッチ処理と かに便利） 複数行まとめて文字置換するときに perl を一時期使っていた for 文をワンライナーで、 for fi le in `ls -1` ; do echo $ fi le ; done 的なことはよくやる grep は偉大
- 35. Tips4: 最低限のドキュメントの準備 • 構成図 • システムマップ図、IPアドレスアサイン表、物理構成図、論理構成図、プロトコルフロー図 • ディレクトリ構成、コンテナの構成、ミドルウェア設定、ログ設定 システムマップ図 いわゆるポンチ絵。 システムの機能別にオブジェクトを配置して、なんの役割をしているか明 確にします。 論理構成図 L7、L3の情報を洗い出す。 単体の情報だと構成図として役割として微妙だが、通信別の流れを明らかにす ることで、どのようにメンテナンスするか、どのように監視するかなどが明確 になるます。L2のスイッチは基本的に書きませんが、メンテナンス用にIPアド レスが振られている場合は記載対象となるため注意が必要です。 物理構成図 物理的な構成を書く図です。 主にマシン名、ポート、VLANの関係などを洗い出すことが役割になりま す。たまに変態構成をとる場合は、物理構成図が芸術的になり可読性を保 つことを第一に考えます。 プロトコルフロー図 論理構成図を背景として、各ポート別の通信の流れを情報として洗い出す。 止めていい通信・ルーティングを可視化し、手順書を書くときに、どの通信が 止めるか、経路の変更をするかなどを検討するために必要となります。
- 36. Tips5: 手順書等がないときの初動 • 考古学の実施をしないといけないとき • 設計書を探す時は過去に担当者の名前を見つけることが最優先です。 • 時系列の組織図は必ず総務か人事が握っているので相談して手に入れましょう。 • サーバーに実際にログインして、セキュリティがざるなら、 sudo su しまくって過去のコマンドを調べていきます。 • 共有ドライブには必ず遺言があります見つけましょう。 人間は感情の生き物なので、前任者がまっとうなエンジニアならスコープと運用 方針を書いてくれています。（逃げろと書いていたら、全速力で逃げます)
- 37. Tips6: コンフィグのポリシーの見つけた方と作り方 • コンフィグの読み方、法則性を抜き取る • 現場に入り込むことができたら、ネットワーク機器・サーバーのコンフィグを並べます。特 に並列でならんでいる隣にある機器設定は重要です。 • ベンダー製品にはコンフィグのリズムがあり、並列で並べる場合は、同じ様なコンフィグな 部分とパラメータだけが違っている部分の2種類が発生することが多いです。 • 3つ以上のコンフィグを確認できたら、設計図等を見つけ出し、テンプレートとなる設定を みつけだして、比較を開始します。 • 1つだけのコンフィグやテンプレートを基準にしてしまうと、運用であとからつけたコンフィ グやパラメータに気づけなくなるため、現場に入ったらひたすらコンフィグを読む様にして います。
- 38. FYI：Ansibleはありか？なしか？ 手順書としてはあり/ 引継資料としてはなし 引継資料として playbook のみを渡されたら、何を意図してコマンドが実施 されたかが不明になるため、ドキュメントが別途必要になる認識です。
- 39. FYI：メンテナンスアナウンス サービスを利用している人たちにメンテナンスやりますよ！と予告することが一 般的だと思います。 ここは技術関係ないところなので、フォーマットを先に作って組織内で決まっ た形を作っていると揉めることが減ります。
- 40. FYI：失敗談 • 手順書の引き継ぎ（興味がない人への対応） 誰に引継作業を行うかはかなり重要です。 引継対象者がコマンドに精通していない、ネットワークを理解していないパターン は割と多いです。 知識がないなら教育で済みますが、興味がない人は門前払いします。 教えても運用に入ってからの費用対効果が薄く、損するパターンが100％のため。 • パワーシェル失敗談 過去に 600 行の PowerShell を作成したことがありますが、その後のメンテナン スが不可能になりました。Teratermマクロを生成＆実行を繰り返す PowerShell とか黒魔術すぎて引継不可ですよね。
- 41. おしまい
- 42. • 以下の素材やスライドデザインを参考にしました。 • プレゼンテーション用アイコン(yuyarinさん) https://github.com/yuyarin/presentation_icons • 運用自動化、不都合な真実(波田野さん) https://speakerdeck.com/opelab/20171212-automation • スペシャルサンクス
