コンテナに積み込もう

コンテナ入門から移行まで

http://bit.ly/tsumikomou

自己紹介

たまるつかさ T.M.R.

Google で GCP のカスタマーエンジニアやってます

GCPUG Shonan / Yokohama もやってます

最近はよく地方の GCPUG に出没しています

昔は某ハイブリッド書店のアーキテクトしてました

今日はその時の経験に基づくお話

話すこと

  • コンテナのおはなし
  • コンテナに移行しよう

今日はコンテナオーケストレーションな話はしません

コンテナ移行対象もどちらかというとレガシーな感じのモノリシックアプリケーションをターゲットで考えています

おことわり

今日の内容は私個人の意見であって所属企業を代表するものではありません

コンテナのおはなし

そもそもコンテナってなんでしたっけ

コンテナはアプリケーションコードとその依存性を一つのユニットとしてまとめる

これにより、アプリケーションとインフラを疎結合にすることができる

  • コンテナはアプリケーションとその依存性がまとまっているので、例えば、開発環境、テスト環境、本番環境をまたいだデプロイが容易になる
  • オンプレミス、プライベートクラウド、パブリッククラウド等ことなる実行環境間の移動が容易になる

コンテナ イメージ

依存性

アプリケーション コード

仮想マシンとコンテナの構造の違い

インフラストラクチャー

ホスト オペレーションシステム

ハイパーバイザー

ゲスト

OS

アプリ 1

ライブラリ

ゲスト

OS

アプリ 1

ライブラリ

ゲスト

OS

アプリ 1

ライブラリ

仮想マシン

インフラストラクチャー

ホスト オペレーションシステム

コンテナランタイム

アプリ 1

ライブラリ

アプリ 1

ライブラリ

アプリ 1

ライブラリ

コンテナ

ユースケースの違い

ゲスト

OS

アプリ 1

ライブラリ

仮想マシンの場合

(IaaS のオートスケール対応)

アプリ 1

ライブラリ

コンテナ

ゴールデンイメージと

呼ばれるイメージを作成

スタートアップスクリプト

でアプリ資材を配置

すべてを

イメージに入れ込む

ローカルと同じ事が再現出来る = 可搬性

コンテナ自体は新しい技術ではない

コンテナ技術の歴史

1979

UNIX chroot

FreeBSD Jail

2000

OpenVZ

2005

cgroups

2006

2008

lxc

2013

Docker

2014

Kubernetes

2018

gVisor

コンテナ技術の歴史

1979

UNIX chroot

FreeBSD Jail

2000

OpenVZ

2005

cgroups

2006

2008

lxc

2013

Docker

2014

Kubernetes

2018

  • プロセスのルートディレクトリを変更
  • 変更したファイルシステム上の場所に閉じ込める
  • FTP などで利用される

gVisor

コンテナ技術の歴史

1979

UNIX chroot

FreeBSD Jail

2000

OpenVZ

2005

cgroups

2006

2008

lxc

2013

Docker

2014

Kubernetes

2018

  • コンテナに IP がついた
  • ネットワークが利用できる
  • 管理性、セキュリティの向上

gVisor

コンテナ技術の歴史

1979

UNIX chroot

FreeBSD Jail

2000

OpenVZ

2005

cgroups

2006

2008

lxc

2013

Docker

2014

Kubernetes

2018

  • Linux 上で動作するコンテナ仮想化
  • イメージを作成出来る
  • チェックポイント、リソース管理
  • カーネルをいじって実現

gVisor

コンテナ技術の歴史

1979

UNIX chroot

FreeBSD Jail

2000

OpenVZ

2005

cgroups

2006

2008

lxc

2013

Docker

2014

Kubernetes

2018

  • メモリ、CPUなどのリソースをプロセスグループ単位で制限する技術
  • Google により開発
  • Linux カーネルへマージ

gVisor

コンテナ技術の歴史

1979

UNIX chroot

FreeBSD Jail

2000

OpenVZ

2005

cgroups

2006

2008

lxc

2013

Docker

2014

Kubernetes

2018

  • 軽量コンテナ
  • Namespace + cgroups で名前空間も分離して、Linux の標準機能でコンテナを実現

gVisor

コンテナ技術の歴史

1979

UNIX chroot

FreeBSD Jail

2000

OpenVZ

2005

cgroups

2006

2008

lxc

2013

Docker

2014

Kubernetes

2018

  • 開発者による圧倒的な支持により一躍コンテナ時代へ

gVisor

Docker とは?

アプリ開発者にフォーカスしたコンテナ

環境を煩わせない

  • ソーシャル
  • Git ライクな変更管理 (Union FS)

コンテナを簡単に使えるようにした

Docker Hub

(コンテナイメージ共有)

Docker Engine

(ランタイム、パッケージング)

ベースイメージ

Change A

Change B

Change C

FROM ubuntu:18.04
RUN echo "Hello world" > /tmp/change

change : 783cef875

Docker と それ以前のコンテナ

ベースイメージ

(Vanilla Ubuntu + α etc.)

Change A

Change Z

Docker Hub で共有

アプリ開発者だけで環境構成ができる

アプリ開発者が

インストールしたり

変更したものが

Git ライクに履歴管理

される

ベースイメージ

(Vanilla Ubuntu + α etc.)

Change A, B, C … Z

作るのが難しい

隔離出来ても環境構成が難しい

...

変更を追うのが難しい

Dockerfile

アプリ or インフラ担当者が開発

Dockerがもたらしたもの

アプリ開発者が

Dockerfile で定義出来る

アプリケーション実行環境

手元で作って、どこでも動く

コンテナ化するといいこと

  • Immutable
  • どこででも動く、同じものが動く
  • 余計なものが動かない
  • スケールしやすくなる
  • 言語のアップグレードとかの検証が簡単になる
  • 環境構築をDockerfileに一元化できる
  • 開発でアプリケーションの言語やフレームワークが変わっても運用のインタフェースは変わらない
    • docker run … でOK
  • 開発組織が変わる!

コンテナに移行しよう

何から始めればいいか?

  • コンテナ化するアプリケーションを知る(敵を知り己を知れば百戦殆うからず)
    • アプリケーションの種類は?(Webアプリケーション?バッチ?)
    • アプリケーションのI/Oを正確に把握する ← 重要!
    • ポートは?
    • 必要なランタイムは?
    • 関連するプロセスはあるか?
    • 外部コンポーネントはあるか?

何から始めればいいか?

  • どこで動かすか考える
    • まずはローカルで動かしてみよう
    • とにかく試しましょう
    • 本番ではどうする?
      • ここだけはちょっと先のことを考える必要があります
      • 一旦1インスタンスに1 or N コンテナで運用してみる(規模の小さいものならそれもあり)

実際何をすればいい?

  • ログ出力の見直し
  • アプリケーションの見直し(できればやりたくないよね)
  • Dockerfile書く
  • CI/CD ジョブの見直し

ログの見直し

  • 身構えなくても大丈夫
  • ログを標準出力で吐き出すようにするだけ
  • けど、実際の運用とか(ログ収集基盤とかそういう類のやつ)を少し変える必要があるので一旦今までどおり同じパスで吐き出しましょう
    • わりとあるのはログの種類によってファイルを出し分けてるようなやつ
    • ロガーライブラリとかで設定ファイル化してると思うのでそこに手を入れます
    • アプリケーションの実装によってはコード変更が必要かも
  • 最初はこれでOK
  • 追々やっていきましょう

アプリケーションの見直し

  • まずはやらなくてもいい方向でやる
  • モノリシックなアプリだったらまずはコンテナイメージでかくなるのをいとわずやる
  • アプリケーションを切り出していきましょう
    • 長期的なロードマップを用意して開発が必要
    • 覚悟がいる
    • アプリケーションの境界を意識する
    • マイクロサービス化
    • これは最終的な形として目標にしましょう
    • すぐにできなくてもOK

Dockerfile書く

  • コンテナ化のための設計書
  • ベースイメージの選定
    • できれば小さいイメージがいいけど、最小なイメージにすると思わぬところでつまずく可能性があるので一旦今使ってるのと同じOSイメージを使いましょう
    • 思い切ってえいや!でやるときはいつか来る
  • ランタイムのインストール方法を調べる
    • 古の環境から掘り起こすのは大変かもしれませんががんばりましょう
    • まずはランタイムが入った状態のベースイメージを作るところまで
  • アプリケーション配置
    • ビルド済みモジュールなりそのまま配置なりアプリケーションによって違うかと思います
  • 必要な設定があればDockerfileに記述する
    • プロパティファイル中に環境依存の設定値がある場合は外出にしましょう
    • 環境依存の設定値は追々環境変数などにした方がいいです

コンテナイメージロードマップ(例)

1st Stage

2nd Stage

まずはでかくてもいいからコンテナにする。

ログ出力も一旦ホストに出力するようにする。

アプリもモノリシックのままで。

コンテナ化することが大事!

小さいベースイメージを試してみる。

ログの基盤をクラウドベースなものにして出力先を標準出力に切り替えていく。

アプリの切り出しをしていく。

Final Stage

マイクロサービスにしていく。コンテナの動作環境をコンテナオーケストレーションなもので動かせるようにする。ここは人によってはゴールじゃなくてもいい。

コンテナ化が終わったら

まずはコンテナ化終わったあなた、お疲れ様でした

がんばりました

あなたはすごい!

偉業を成し遂げました!!!

Congratulations...! Congratulations…!

だが、本番で使うには

これだけでは終わらない

コンテナ管理の課題

Node

Node

Cluster

Node

???

  • 複数のノードに対するコンテナのデプロイは?
  • ノード障害が発生した場合は?
  • コンテナ障害が発生した場合は?
  • アプリケーションのアップグレードはどうやって管理する?

コンテナ技術の歴史

1979

UNIX chroot

FreeBSD Jail

2000

OpenVZ

2005

cgroups

2006

2008

lxc

2013

Docker

2014

Kubernetes

2018

  • コンテナオーケストレーションの仕組み
  • Google により開発、内部で運用されてきた Borg ベース
  • 必要なリソースを、必要な分だけ
  • 自律回復するインフラ

gVisor

Googleでは 15 年以上にわたり、

すべてのサービスをコンテナで動かしてきた

毎週 20 億以上のコンテナを立ち上げている

Images by Connie Zhou

Copyright 2015 Google Inc

ステップ論で使いこなす

Container on Kubernetes

Container

On local

Container

On IaaS

GCE

GKE

Copyright 2015 Google Inc

おわり

コンテナに積み込もう - Google Slides