読者です 読者をやめる 読者になる 読者になる

smallpalace's blog

鯖缶主婦の日々の記録です

コンテナ支部の#4にいってきた

こんにちは。smallpalaceです。

 

3末にJAWS-UGのコンテナ支部の#4に行ってきましたので備忘録です。

 

https://jawsug-container.connpass.com/event/51776/

ハッシュタグ:#jawsug_ct

https://twitter.com/search?f=tweets&vertical=default&q=#jawsug_ct&src=tyah

あとで↓こちらで配信されると言っていました。

https://crash.academy/

 

 ---

 

前佛さん
CLIなどの話

http://docs.docker.jp/

コンテナは技術、Dockerは使用
DockerHubが中継点
コマンドでコンテナとイメージを操作


技術と仕様

技術はコンテナ、仕様は使用

環境が異なる問題を解決

すべての依存関係をパッケージ化してコンテナとして動かす

LinuxKernelのコンテナ技術:
namespaceとcontrol group(cgroup)の制御により、
プロセス環境をisolate(分離)し、リソースも制御できる
この技術をDockerEngineで制御

LXC,libcontainerを使っていた、
いまはdockerd、containerdとrunCを使っている
(ライブラリとデーモンの話

通常LinuxサーバではinitをプロセスID1としてその下にプロセスがツリー上にぶら下がっているが、
それぞれのコンテナ内ではそれぞれPID1になってる

コンテナ内のファイルシステムも同じように/からはじまっているがホスト側ではマウントされてるようにみえる

Dockerイメージ
・イメージ・レイヤの積み重ね。
・読み込み専用
メタデータのようなものをもつ

Dockerコンテナ
・イメージレイヤを1つのファイルシステムとみなす
・読み書き可能なイメージレイヤを持つ

Dockerイメージは仮想サーバ用のイメージとは違ってプログラムが必要とするファイルしかもっていない

コンテナを実行するときはイメージの上に書き込み可能なレイヤを割り当てている
ログとか。

イメージレイヤには親子関係がある
あるイメージから別のイメージをつくる場合に有効。重複する部分は共有するなどリソースを節約したり差分管理
したり素早く実行したりできる。(gitなどのバージョン管理システムに似てるらしい)

DockerEngineはイメージをコンテナ化してコンテナ技術で動かす

でもコンテナって前からあったよね?Solaris10とか?

その差とは?

ただコンテナ化して置くだけでなく、
構築・移動・実行(Build>Ship>Run)ができるようになった

移動がHubにあたる。
Dockerイメージの保管と共有をするためのリポジトリ(倉庫)

dockerクライアントがrunをすると
dockerエンジンがhubにイメージを問い合わせて(pull)ダウンロードしてコンテナ追加して実行して返す

イメージは並列で送ったりダウンロードしたりできる

hub.docker.com

CIツールとバージョン管理システムでwebhookでpushしたりもできると。

Dockerイメージ操作コマンド

コマンド体系が最近変わった

最近はイメージにかかわるコマンドは
docker image ~という感じになる

コンテナ操作コマンド
これまではdocker runだったが最近はdocker container runになる

いちばんはじめは
docker image pull
でイメージをhubからとってくる

つぎ
docker image ls
ローカルのイメージを一覧表示

docker container run
イメージを実行

docker container ls
(docker ps)

docker image build
イメージの自動構築(ビルド)
Dockerfileからビルドする

docker container commit
コンテナ用レイヤをイメージ化

docker container inspect
コンテナの詳細情報を表示

docker image inspect
イメージの詳細情報を表示

docker container diff
イメージとの差分を表示

docker image history
イメージレイヤと履歴の表示

docker search
ハブのイメージを検索

コンテナ削除はrm
コンテナもイメージもrmできる
コンテナは動いてるやつをけすやつ

pruneでいらないのを丸ごと削除できる

docker system prune
でいらないすべてを消せる

docker system info
docker system df

キータのzenbutuにのってる
http://qiita.com/zembutsu

コピーオンライトでパフォーマンス劣化

http://docs.docker.jp/engine/userguide/storagedriver/imagesandcontainers.html

バイスマッパー
 ストレージドライバを使うしメモリを食う

使ってるOSのデフォルトで違う

ボリュームはコンテナ用のレイヤとは分離されてるのでデータベースとかで採用するといいかも

docker volume
docker networkなどのコマンドもあるよ

https://www.slideshare.net/zembutsu
@zembutsu

QA
コマンド変わったけど内部的な動きは同じ?
→同じです

----
あさのさん

ECS関連アップデート

AWSのソリューションアーキテクト

アップデート結構多いと。

12月からのアップデート
ECRについてレジストリの話も

OSSBloxリリース

https://www.slideshare.net/AmazonWebServices/new-launch-advanced-task-scheduling-with-amazon-ecs-and-blox


 ECSをカスタマイズしたい人向けのツール
  カスタムスケジューラを作りたいとか

WINServerコンテナ対応
 タスク定義のいくつか制限など
 Hiper-vコンテナはEC2上では動かせない

TaskPlacement
 タスクの配置をより柔軟にカスタマイズできる
 binpackはタスクをつめこむ
 spreadにするとタスクを分散する(AZとかインスタンスとかの指定をすることでコンテナをどこにおくのか決められる)

ECRがDockerイメージ。。をサポート

コンテナインスタンスのドレインをサポート
 ほかのタスクに影響を与えずにクラスターからコンテナインスタンスを削除可能に
 タスクがいなくなってからホスト削除するとか

コンテナインスタンスのドレイン自動化実装例も

ライフサイクルフックでインスタンスのterminate。waitを検知してSNS経由でlamdaファンクションをinvokeするとか
lamdaファンクションによりコンテナインスタンスの状態を。。うつせず

ECS-optimizedAMIの更新通知がSNSで受信可能に。
リージョン単位

EC2ContainerRegistry(ECR)
つまりAWS上のDockerHubかな
フルマネージドでよい自分らで運用しなくていい
DockerHubは日本にないのでレイテンシが問題
コンテナイメージはHTTPS送信され保存は暗号化。
IAMとのインテグレーションできるので安全。クロスアカウントもできる

認証用のクレデンシャルヘルパー。使わないとlogin処理が必要になるので手間。

https://github.com/awslabs/amazon-ecr-credential-helper

試してみてね!

----
とださん

コンテナ支部の人

@thiro1123

とある社内ビックデータ基盤にバッチ用コンテナ環境を構築してみた

会社名は秘密だそうです

導入の背景
バッチが300以上ありサーバ80以上の上に様々なOSやミドルや言語やライブラリやなにやら蜜結合して検証がうまくいかないケースが。
アップデートすると動かないとか日々おこる
事業担当者に怒られるクレームドリブン問題のプロジェクトであった
アラートモニタリングだけで追いつかない
一つのバッチうごかすのに1か月かかる

現在は、新しいことしたらその倍の問題が発生はしない環境

社員の人に「ライブラリの競合がいやならコンテナにしては?」といったら了承3秒。

JP1からバッチ管理したいと。APIゲートウェイつかってる
ラムダ→SQS→ECS
デプロイや環境構築はjenkinsのジョブで自動化してると

QA 
・コンテナのイメージ数は?
→オンプレにいるやつもまだいる。データ分析用のやつが2,3個で検証段階
 やっとつくったところで絶賛推進中。ほかにも広めてるところ

 改善するために分離できるようにがんばっている

・ログをとるとき?コンテナでどうしてる?
→きほんCloudWatchlogsとかS3とかデータベースとか側に送るようにしてる。ボリュームは使わないほうこう
 管理が大変になるので
 できるだけ状態を持たないようにしてくださいと言ってる

・オンプレのAPIゲートウェイ
→オンプレのサーバにはなにもいれない。Linuxにはcurlがある。

----
NTTソフトフェアの須藤さん
あさってからNTTテクノクロスにいく

社内研修の講師とか検証とか
社内ではAWSの回し者といわれている。ECSとラムダがすき

NTTとDocker,Containerときいて?
結構深いつながりがある
DockerEngineとetcdとかInfraKitとDockerTokyo OrganizerなどのメンテナとかをNTTのSICから排出してる

わたしは
社内検索エンジンOnDockerをつくったり
備蓄品安心サポートというBtoCのサービスをECS上に構築するなど

ECSの導入メリット
 アプリのデリバリサイクルを早める
 アプリとインフラの責任分界点が明確、インフラがマネージドサービスになるので劇的に負担が減る
 インスタンスとサービスの分離。マイクロサービスの追加がより容易になる。サービスとインスタンス疎結合になる
 サービスを追加するときにやる作業量が減る
 価値提供が迅速になる
 運用コストを抑えられる。ECS+SpotFleetと組み合わせると。オンデマンドと比べて51.7%削減した数字を弊PJでもってる
 運用オペレーションが簡単になる。人間のオペレーション時間が減るので運用コストが削減される
 多くの場合インスタンスよりエンジニアのコストのほうが高い

ECS導入の勘所
 なんでも乗せ換えると幸せになるわけでもない。知っておいてほしいことがある。

タスクとかタスクでふぃにしょんとかわからなければブラックベルトの資料みるといいよ

https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-2016-amazon-ec2-container-service

なるべくDockerVolumeを使わなくていいように設計する
Volumeを使うとコンテナインスタンスがImmiutableでなくなるのでクラスタのメリットが損なわれる
ファイルはS3へログはCloudwatchLogsへ永続化データはRDSやDynamoDBへ
ログについてはawslogsというログドライバがあるのでそれを使うのが基本
標準出力をCloudWatchlogsに転送してくれる
 ログローテートやログファイルの考慮が不要
fluendとかほかのログドライバの検討
 ハイブリッドとかマルチクラウドとかすでに仕組みがある場合に検討するとよさそう

パスの設計(URL設計)
ALBのパスベースルーティングの利用
 ドメイン名を分ける必要のないServiceは何か?
 多数のサービスがある場合、それと同数のALBを作るとこすとが膨らみやすい
 パスベースルーティングで1つのALBに複数のサービスをぶら下げられる

データソース設定
 コンテナに埋め込まないですむやつ
 環境変数やRoute53のPrivateHostedZoneの利用でRDSのエンドポイントをコンテナイメージに埋め込まないように。

セッション管理
 ALBのStickySessionを使う
  タスクが停止するとセッションが切れる
  SpotFleetだとインスタンスが変わるタイミングは予測できない
  頻繁にサービスを更新するような(タスクが停止起動する)場合はこれだけだとつらい
 StateStoreを使う構成にする
  ElastiCacheでRedisとmemcacheつかうとよい
  アプリではspring-boot-starter-redisやSpringSessionなどで

アプリの作りはコンテナベースのサービスに向くか結構重要

環境構築時注意すること
 コスト最適化
  ECSはSpotFleetとの相性が非常に良い

最新のECS-optimizedAMIを使うとよい
 DockerやECSのバージョンアップで更新される
 脆弱性対応が通知されたら最優先でクラスタの更新を。
  新しいSpotFleetをクラスタに追加
  古いインスタンスをすべてドレイン
  古いSpotFleetをキャンセル

ECSでのServiceDiscovery
 Taskの変動に応じてターゲットグループ(インスタンスとポート)をメンテナスしてくれる機能がある
 構築時にしか指定できない

1.からのECSクラスタをつくる
2.SpotFleetをつうkるインスタンスロールに特定のやつをアタッチしないといけないのとユーザデータでECS_XLUSTERを指定
3.ALBとからのたーぎえっとグループを作る
。。。6つがだいじらしいがうつせず
ポイントを押さえて幸せに

QA
・負荷のところで気になったのがRoute53だとキャッシュとかどんなもんかな
→R53そんなにしらないがプライベートの場合は解決がすごく早いので大丈夫なのでは
→ログの転送がfluentd+CloudWatchLogsでPrivateHostedZoneで解決して送ってるがログの遅延はロストはない
→DBの場合アプリでコネクションプールしてる場合はトランザクションのたびにDNS引く動きにはならない
----

 

というわけで備忘録でした。みていただきありがとうございました!