LoginSignup
1
0

More than 3 years have passed since last update.

【AWS Summit2019】@幕張メッセに行ってきた 6/14

Last updated at Posted at 2019-06-15

AWS Summit幕張の最終日に仕事をサボって行ってきました。

  • 目的
    • コンテナ系の技術セッションに参加すること
    • AWSのコンテナのExpertに質問をすること
    • その他ブースをふらつく

コンテナ系の技術を学ぶため、というのが一番の目的でした。
自宅でちょこちょこ触っているだけなので、実業務ではどのように使われているのか、ベストプラクティス、アンチパターンを確認したいためです。

コンテナとは?

自身の復習のためにさらっと。
事実上Dockerと言っていいほどデファクトスタンダードになっているため、以下コンテナはDockerと表現します。
DockerとはDockerエンジン上で立ち上がるそれぞれに完全に隔離された空間です。
よく仮想マシンとコンテナの比較が上がります。イメージで表すと以下です。
引用

Docker入門(第一回)~Dockerとは何か、何が良いのか~

VM_Container-680x387.jpg

仮想マシンがハイパーバイザー上でゲストOSを乗せて動作しているのに対し、Dockerはエンジン上でコンテナが立ち上がります。
外から見ると両者はあまり違いはないかもしれません。(アクセス方法などに少し差があるくらいでしょうか)
よくDockerは仮想マシンに比べ高速だといわれていますが、この理由がここにあります。
仮想マシンはミドルウェアに相当するのですが、Dockerはプロセスです。
互いに隔離されたプロセスが立ち上がるだけなので非常に高速です。(というのを昨日のセッションで聞いて、あ!なるほど!と思いました。)
そしてDockerは四角で囲まれている部分を一つのイメージにして持ち運ぶことができるため、エンジンさえ入っていればどんな環境でも簡単に移行させることができます。
図にあるアプリの実行環境もイメージの内部にあるため、ホストOSも問いません。

How to use Container?

本題のどのようにしてコンテナは利用されているか、ベストプラクティス、アンチパターンを聞いてきました。

  • コンテナは1コンテナ1プロセスであること
    さて、上記にある図を早速否定されました。原則、コンテナとプロセスは1:1にするのがベストプラクティスとされています。
    ミドルウェアとアプリのコンテナは分離してイメージ化するのがよいでしょう。

  • コンテナに向いているアプリケーションとそうではないアプリケーション
    リソースさえあればイメージはどんなものでも作れます。が、Dockerを使ったほうがよいもの、そうでないものは当然あります。
    以下のように切り分けるのがよいのではないか、と教えてもらいました。
    ・読み取り専用で実行したとき、問題なく動作させることができること
    Dockerはデータを永続化させることができないため、(厳密にはホストOSにボリュームをマウントできるのでそうではないかもしれませんが、アンチパターンな気がします。)ファイルやデータの書き出しを行わないものであればDockerを利用することが検討できそうです。
    ※蛇足 DockerでホストOSにデータの書き出しはできますがFargateを使うと死亡します。というのもFargateは自動でスケールイン、スケールアウトを行うのでEC2が落ちたり立ち上がったりするからです。

  • Dockerを使ったデプロイメント
    個人的に考えているのはこのパターンかな、と。(アプリケーションサイドのパターンです)
    ・Gitなどにソースがコミットされたら、自動でイメージを作成、デプロイ、イメージのpush
    別セッションでAWS CodePipelineを利用したCI/CDパターンが紹介されていました。
    これはECRにイメージがpushされたことを契機にCI/CDが動作していました。ただ、これだとインフラサイド(ランタイムなどアプリの動作環境)とアプリケーションサイドが分離されていなくてイマイチじゃないかなぁと思いました。
    課題はタグをどうするかということでしょうか。

  • Dockerを使った開発
    インフラ周り、アプリケーション周りが分離されている場合はこのようなパターンがベストではないかと。
    スクリーンショット 2019-06-15 11.30.05.png
    各開発者はローカル環境でテストを行うとき、お互いの最新資源で確認ができます。

  • Dockerのイメージサイズについて
    各イメージのサイズは数Mから大きくても数十Mが標準的なんだと聞きました。
    Rubyの公式サイズのイメージは…うごごご
    2019/07/20追記
    とか書きましたけど、開発用なのである程度大きいのも普通なのかもしれません。

REPOSITORY                  TAG                 IMAGE ID            CREATED             SIZE
ruby                        2.6.1               99ef552a6db8        3 months ago        876MB

感想

はっきり言って、完全に遊びに行った感覚でしかなかったんですが学びは多かったです。
コンテナのことに限らず、様々な業界の企業が出展していたので業界トレンドや各社のセールスポイントを聞くことができました。
また、AWSの方々や企業ブースの方々は非常に優しくまさかりが一本も飛んで来ませんでした。
ズタズタになる覚悟をしていきましたが。。。
あと、TISの方とOracleCloudの話で若干盛り上がりました。AWSのイベントなのに・・・

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0