https://www.redhat.com/cms/managed-files/cl-cloud-native-container-design-whitepaper-f8808kc-201710-a4-ja.pdf
単一関心の原則
1-コンテナ 1-関心事
1関心コンテナをn個組み合わせてデプロイユニット(Pod)にする
サイドカーとかでまとめる
たとえばログ集約したいなら、それ用のコンテナをサイドカーにする
そうすればログ側修正したいときも、そのログ用コンテナをいじれば（利用側）全部反映できる🐰
高観測可能性の原則
ログ、メトリクス、トレースを担保する
ログ
コンテナはstderr、stderrに出せ。個別にログ処理作り込むな
ログは集約しろ
jsonで扱うと処理しやすい
人間が読むのは苦しくなるが🐰
メトリクス
設計段階から準備必要
たとえばアクティブユーザー数がほしいならログにユーザーidとか出さないといけない
メモリ、ディスクio、スケーリングアウト時間などは要チェック三銃士
トレース
E2Eレベルで全部追う
フロントエンドの組み込み
console.logに出してるアプリもあるよね🐰
クラウドサービスがサポートしてるならそれ使うと置いやすい
AWSのX-Ray
ライフサイクル適合の原則
コンテナはいつ死ぬかわからんので、死ね(sigtermとかsigkillとか)と言われたら死ねるようにつくっておくべき
クラウドサービスやコンテナ基盤によっては他にも色々ステータスメッセージがあるので、必要ならキャッチする
AWS ECSでも「まもなく終了します」的なやつがあったよね🐰
イメージ不変性の原則
コンテナはイミュータブルにして冪等性を確保しろ
≒コンテナに設定情報やビルドツールやビルド処理を入れるな
設定情報は外に出せ、ハードコードもせず別ファイルに分けて.gitignoreとかも上手く使え
ビルド情報は内包しろ（最初から入れとけ）
外の設定情報の渡し方、大まかには
環境変数で渡す
コンテナに設定ファイルを渡すなり、コンテナから読み込ませるなり
コンテナからAPI叩かせて読み込ませる
プロセス廃棄性の原則
コンテナはいつでも死ねるようにしておけ
状態持つな、外に出せ
ログは都度出しておけ
バッキングサービスへの対処も頑張れ
サーキットブレーカーも使える
そもそもコンテナを小さくして起動終了時間を抑えろ
普段は大丈夫だけどメモリ不足で対応できないなんてケースもある
ので対応できなくなったコンテナはもう切り離しておけ
ライフサイクルとも被ってるが、まあグレースフルシャットダウンってことだな🐰
自己完結性の原則
コンテナは自分の動作に必要なrequirementsすべてを自分で持て
設定は例外（外に出せ）
Q:データベースを使うwebアプリコンテナの場合は？DBもwebサーバーも両方入れる？
ちゃう
DBコンテナとwebサーバーコンテナを二つ用意して通信させろ
前者はdb、後者はwebサーバーとして動作するに足るものを全部持て
ランタイム制限の原則
コンテナは自分の動作に必要な上限リソース量を定義しておき、それ超えたら死ね
実行プラットフォームに渡してそのとおりに動かせるようにしておけ
ECSで言えばcpuとかmemoryとかあの辺の値やな🐰
Q:なんで？
コンテナ一つがリソース食いつぶしまくると他に迷惑かかるからや
コンテナは仕様上、ホストのリソースを皆で奪い合う形態になる。誰かが独占したらみんな死ぬんや
softlimitとhardlimit
---