Flask Mega-Tutorial、パートXIX：Docker Container Deployment

（2018年版）

ミゲル・グリンバーグ

ここに 戻る

これはFlaskメガチュートリアルシリーズの第19回目で、DockerプラットフォームにMicroblogを展開します。

ネタバレの下には、この2018年シリーズのすべての記事のリストがあります。

注1：このコースの古いバージョンをお探しの場合は、こちらをご覧ください 。

注2：私（ミゲル）の仕事を支持して突然声をかけたい場合、または1週間記事を待つ忍耐がない場合、私（ミゲルグリーンバーグ）はこのガイドの完全版（英語）を電子書籍またはビデオの形式で提供します。 詳細については、 learn.miguelgrinberg.comをご覧ください 。

第17章では、サーバー構成のあらゆる側面を処理する従来の展開について学習しました。 次に、 第18章で 、構成タスクと展開タスクを完全に制御するサービスであるHerokuを紹介したときに、もう1つの極端な方法を紹介しました。 この章では、特にDockerコンテナプラットフォームでのサードパーティのコンテナベースのアプリケーションの展開戦略について学習します。 この3番目のオプションは、他の2つの間の「ゴールデンメーン」です。

コンテナーは、単純化された仮想化テクノロジーに基づいて構築されているため、アプリケーションはその依存関係と構成とともに完全に分離して動作しますが、仮想マシンなどのフル機能の仮想化ソリューションは必要ありません。ホストと比較して。 コンテナノードとして構成されたシステムは、ホストコアを共有し、ホスト機器に直接アクセスできる多くのコンテナを実行できます。 これは、プロセッサ、ディスク、その他のハードウェア、カーネルなどを含む完全なシステムをエミュレートする必要がある仮想マシンとは対照的です。

カーネルを共有していないにもかかわらず、コンテナ内の分離レベルは非常に高くなっています。 コンテナには独自のファイルシステムがあり、コンテナノードで使用されるオペレーティングシステム以外のオペレーティングシステムに基づくことができます。 たとえば、FedoraホストでUbuntu Linuxベースのコンテナーを実行できます。逆も同様です。 コンテナはLinuxオペレーティングシステムに固有のテクノロジーであるという事実にもかかわらず、仮想化のおかげで、WindowsおよびMac OS XホストでLinuxコンテナを実行できます。 これにより、開発システムで展開をテストしたり、必要な場合にのみ開発ワークフローにコンテナを含めることができます。

この章のGitHubリンク： Browse 、 Zip 、 Diff 。

Docker CEをインストールする

Dockerが唯一のコンテナープラットフォームではありませんが、Dockerが最も人気があるため、私の選択になります。 サブスクリプションベースの無料コミュニティエディション（CE）とエンタープライズエディション（EE）の2つのDockerリリースがあります。 このチュートリアルでは、Docker CEで十分です。

Docker CEを使用するには、まずシステムにインストールする必要があります。 Docker Webサイトには 、Windows、Mac OS X、およびいくつかのLinuxディストリビューション用のインストーラーがあります。 Microsoft Windowsを実行している場合、Docker CEにはHyper-Vが必要であることに注意することが重要です。 インストーラは必要に応じてこれを有効にしますが、Hyper-Vを有効にするとVirtualBoxなどの他の仮想化テクノロジーが機能しなくなることに注意してください。

システムにDocker CEをインストールした後、ターミナルウィンドウまたはコマンドプロンプトで次のコマンドを入力して、インストールが成功したことを確認できます。

$ docker version Client: Version: 17.09.0-ce API version: 1.32 Go version: go1.8.3 Git commit: afdb6d4 Built: Tue Sep 26 22:40:09 2017 OS/Arch: darwin/amd64 Server: Version: 17.09.0-ce API version: 1.32 (minimum version 1.12) Go version: go1.8.3 Git commit: afdb6d4 Built: Tue Sep 26 22:45:38 2017 OS/Arch: linux/amd64 Experimental: true 

コンテナーイメージの構築

マイクロブログのコンテナーを作成する最初のステップは、そのためのイメージを作成することです。 コンテナイメージは、コンテナの作成に使用されるテンプレートです。 コンテナファイルシステムの完全なビューと、ネットワーク、起動オプションなどに関連するさまざまな設定が含まれています。

アプリケーションのコンテナイメージを作成する最も簡単な方法は、使用するベースオペレーティングシステム（Ubuntu、Fedoraなど）のコンテナを実行することです。）、実行中のbashシェルプロセスに接続し、アプリケーションを手動でインストールします。従来の展開については、 第17章で説明した推奨事項に従ってください。 すべてをインストールしたら、コンテナの写真を撮ることができます。これは画像になります。 このタイプのワークフローはdockerチームによってサポートされていますが、新しいイメージを作成する必要があるたびにアプリケーションを手動でインストールするのは便利ではないため、これについては説明しません。

最善のアプローチは、スクリプトを使用してコンテナイメージを作成することです。 スクリプトでコンテナイメージを作成するコマンドはdocker buildです。 このコマンドは、まだ作成していないDockerfileからビルド命令を読み取り、実行します。 Dockerfileは、実際には、アプリケーション展開のインストール手順と一部のコンテナ設定を実行するインストールスクリプトです。

マイクロブログ用の基本的なDockerfileは次のとおりです。

Dockerfile：マイクロブログ用のDockerfile。

 FROM python:3.6-alpine RUN adduser -D microblog WORKDIR /home/microblog COPY requirements.txt requirements.txt RUN python -m venv venv RUN venv/bin/pip install -r requirements.txt RUN venv/bin/pip install gunicorn COPY app app COPY migrations migrations COPY microblog.py config.py boot.sh ./ RUN chmod +x boot.sh ENV FLASK_APP microblog.py RUN chown -R microblog:microblog ./ USER microblog EXPOSE 5000 ENTRYPOINT ["./boot.sh"] 

Dockerfileの各行はコマンドです。 FROMコマンドは、新しいイメージの構築に基づいてコンテナのベースイメージを指定します。 アイデアは、既存のイメージから始めて、いくつかの機能を追加または変更し、最終的に派生したイメージにすることです。 画像は、コロンで区切られた名前とタグによって参照されます。 このタグはバージョン管理メカニズムとして使用され、コンテナイメージがいくつかのオプションを提供できるようにします。 選択したイメージの名前はpythonです。これは、Pythonの公式Dockerイメージです。 このイメージのタグを使用すると、インタープリターのバージョンとベースオペレーティングシステムを指定できます。 3.6-alpineタグは、Alpine LinuxにインストールされているPython 3.6インタープリターを選択します。 Alpine Linuxディストリビューションは、サイズが小さいため、Ubuntuなどの一般的なディストリビューションの代わりによく使用されます。 PythonイメージリポジトリでPythonイメージに使用できるタグを確認できます 。

RUNコマンドは、コンテナのコンテキストで任意のコマンドを実行します。 これは、シェルコマンドプロンプトでコマンドを入力するのに似ています。 adduser-D microblogコマンドは、 adduser-D microblogという名前の新しいユーザーを作成します。 ほとんどのコンテナイメージにはデフォルトユーザーとしてrootがありますが、アプリケーションをルートとして実行することは推奨されないため、独自のユーザーを作成します。

WORKDIRコマンドは、アプリケーションがインストールされるデフォルトのディレクトリを設定します。 上記のmicroblogユーザーを作成すると、ホームディレクトリが作成されたため、このディレクトリをデフォルトにします。 新しいデフォルトディレクトリは、Dockerfile内の残りのすべてのコマンドに適用されます。また、コンテナが実行されるときにも適用されます。

COPYは、コンピューターからコンテナーファイルシステムにファイルを転送します。 このコマンドは、ソースと宛先のファイルまたはディレクトリの2つ以上の引数を取ります。 ソースファイルは、Dockerfileが置かれているディレクトリに関連している必要があります。 割り当ては、絶対パスでも、前のWORKDIR指定されたディレクトリからの相対パスでもWORKDIR 。 この最初のコピーコマンドでは、 requirements.txtファイルをコンテナーファイルシステムのmicroblogユーザーホームディレクトリにコピーします 。

これで、コンテナ内にrequirements.txtファイルができましたRUNコマンドを使用して仮想環境を作成できます。 最初に作成してから、すべての要件を設定します。 要件ファイルには一般的な依存関係のみが含まれているため、Webサーバーとして使用するgunicornを明示的にインストールします。 または、 requirements.txtのファイルにgunicornを追加できます 。

コンテナへのアプリケーションのインストールに続く3つのCOPYコマンド。 アプリパッケージ、データベース移行を伴うmigrationsディレクトリ、トップレベルディレクトリからのmicroblog.pyおよびconfig.pyスクリプトをコピーします。 さらに、新しいboot.shファイルをコピーします。これについては、以下で説明します。

RUN chmodは、この以前は不明だったboot.shファイルが実行可能ファイルとして正しくインストールされるようにします。 Unixベースのファイルシステムを使用していて、ソースファイルに実行可能ファイルのフラグが既にある場合、実行可能ビットもコピーされたファイルに設定されます。 Windowsでは実行可能ビットを割り当てるのがより難しいため、明示的なインストールを追加しました。 Mac OS XまたはLinuxを実行している場合、おそらく必要ではありませんが、いかなる場合でも問題はありません。

ENVコマンドは、コンテナ内の環境変数を設定します。 FLASK_APPコマンドを使用するために必要なFLASK_APPを設定する必要があります。

次のRUN chownは、 / home / microblogに新しいmicroblogユーザーとして保存されているすべてのディレクトリとファイルの所有者を設定します。 このユーザーをDockerfileのルートで作成したにもかかわらず、すべてのコマンドのデフォルトユーザーはrootままであるため、これらのすべてのファイルをmicroblogユーザーに切り替えて、コンテナーの起動時にこのユーザーが操作できるようにする必要があります。

次の行のUSERコマンドは、この新しいmicroblogユーザーを、以降の指示のデフォルトとして、またコンテナを起動するときのデフォルトにします。

EXPOSEコマンドは、サーバーのポートを構成します。 これは、Dockerがコンテナ内のネットワークを適切に構成できるようにするために必要です。 標準ポート5000を選択しましたが、どのポートでもかまいません。

最後に、 ENTRYPOINTコマンドは、コンテナの起動時に実行する必要があるコマンドのデフォルトを定義します。 これは、アプリケーションWebサーバーを起動するコマンドです。 すべてがうまく整理されるように、私はこのために別のスクリプトを作成することにしました。これは以前にコンテナにコピーしたboot.shファイルです。 このスクリプトの内容は次のとおりです。

boot.sh：Dockerコンテナーの起動スクリプト。

 #!/bin/sh source venv/bin/activate flask db upgrade flask translate compile exec gunicorn -b :5000 --access-logfile - --error-logfile - microblog:app 

これはかなり標準的な起動スクリプトであり、 第17 章と第18 章で展開が開始された方法に非常に似ています。 仮想環境をアクティブにし、移行プラットフォームを介してデータベースを更新し、言語翻訳をコンパイルし、最後にgunicornでサーバーを起動します。

gunicornコマンドの前にあるexecに注意してください。 シェルスクリプトでは、 execは、新しいプロセスとして開始するのではなく、指定されたコマンドで置き換える必要があるスクリプトを実行するプロセスを開始します。 これは重要です。Dockerは、コンテナの寿命を、コンテナで実行される最初のプロセスに関連付けるためです。 このような場合、スタートアッププロセスがコンテナのメインプロセスではない場合、コンテナがDockerで早期に終了しないように、メインプロセスがこの最初のプロセスに取って代わることを確認する必要があります。

Dockerの興味深い側面は、 stdoutまたはstderr書き込まれるすべてのコンテナ出力がキャプチャされ、コンテナログとして保存されることです。 このため、 --error-logfileと--error-logfileの最後に-があり、ログを標準出力に--error-logfileしてDockerログとして保存します。

作成されたDockerfileを使用して、コンテナーイメージを作成できるようになりました。

 $ docker build -t microblog:latest . 

docker build渡される-t引数は、新しいコンテナーイメージの名前とタグを指定します。 . コンテナを作成するベースディレクトリを示します。 これは、Dockerファイルが置かれているディレクトリです。 ビルドプロセスは、Dockerファイル内のすべてのコマンドを評価し、独自のマシンに保存されるイメージを作成します。

docker imagesローカルで使用する画像のリストを取得できます：

 $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE microblog latest 54a47d0c27cf About a minute ago 216MB python 3.6-alpine a6beab4fa70b 3 months ago 88.7MB 

このリストには、新しいイメージと、それが作成されたベースが含まれます。 アプリケーションに変更を加える場合、ビルドコマンドを再度実行してコンテナイメージを更新できます。

コンテナ打ち上げ

イメージがすでに作成されているので、アプリケーションコンテナのバージョンを起動できます。 これは、通常、多数の引数をとるdocker runを使用して行われます。 最初に、簡単な例を示します。

 $ docker run --name microblog -d -p 8000:5000 --rm microblog:latest 021da2e1e0d390320248abf97dfbbe7b27c70fefed113d5a41bb67a68522e91c 

--nameパラメーターは、新しいコンテナーの名前を提供します。 -dは、Dockerにバックグラウンドでコンテナーを開始するように指示します。 -dスイッチを使用しない場合、コンテナはフォアグラウンドアプリケーションとして実行され、コマンドラインがブロックされます。 -pは、コンテナポートをホストポートにマップします。 最初のポートはホストコンピューターのポートで、右側のポートはコンテナー内のポートです。 上記の例では、ノードのポート8000​​のコンテナーにポート5000を提供するため、内部コンテナーが5000を使用している場合でも、8000でアプリケーションにアクセスします--rmは、終了時にコンテナーを削除し--rm 。 これは必須ではありませんが、通常、終了または破損したコンテナは必要ないため、自動的に削除できます。 最後の引数は、コンテナイメージの名前とコンテナに使用されるタグです。 上記のコマンドを実行した後、 http：// localhost：8000でアプリケーションにアクセスできます。

docker runの結果は、新しいコンテナに割り当てられた識別子（ID）です。 これは、後続のコマンドでコンテナを参照する必要があるときに使用できる長い16進数文字列です。 実際、識別子を一意にするために必要なのは最初の数文字だけです。

実行中のコンテナを確認する場合は、 docker ps使用できます。

 $ docker ps CONTAINER ID IMAGE COMMAND PORTS NAMES 021da2e1e0d3 microblog:latest "./boot.sh" 0.0.0.0:8000->5000/tcp microblog 

ご覧のとおり、 docker psでさえコンテナーIDを短縮します。 コンテナを停止する必要がある場合は、 docker stop使用します。

 $ docker stop 021da2e1e0d3 021da2e1e0d3 

アプリケーション構成には、環境変数から取得されるいくつかのパラメーターがあります。 たとえば、Flask秘密鍵パラメーター、データベースURL、および電子メールサーバーは、環境変数からインポートされます。 上記のdocker run例では、それらについて心配していなかったため、これらの構成オプションはすべてデフォルト値を使用します。

より現実的な例では、これらの環境変数はコンテナ内に設定されます。 前のセクションで、 Dockerfileの環境変数の設定はENVコマンドによって行われることを見ましたが、これは静的変数の便利なオプションです。 ただし、インストールに依存する変数については、ビルドプロセスの一部として使用することはできません。これは、持ち運びが簡単なコンテナのイメージが欲しいからです。 アプリケーションをコンテナイメージとして別のユーザーに転送する場合は、他の変数でアプリケーションを再構築するのではなく、このユーザーがアプリケーションをそのまま使用できるようにする必要があります。

したがって、ビルド時の環境変数は便利ですが、 docker runを使用して設定できるランタイム環境変数も必要です。これらの変数には-eスイッチを使用します。 次の例では、Gmailアカウントの秘密鍵とメールを設定します。

 $ docker run --name microblog -d -p 8000:5000 --rm -e SECRET_KEY=my-secret-key \ -e MAIL_SERVER=smtp.googlemail.com -e MAIL_PORT=587 -e MAIL_USE_TLS=true \ -e MAIL_USERNAME=<your-gmail-username> -e MAIL_PASSWORD=<your-gmail-password> \ microblog:latest 

コマンドラインでdocker runされるdocker runこのような長さは、環境変数の多くの定義が存在するため、珍しいことではありません。

サードパーティの「コンテナ」サービスの使用

Microblogのコンテナバージョンは良いように見えますが、これまでストレージについてはあまり考えていませんでした。 問題は、環境変数DATABASE_URL設定しておらず、アプリケーションがディスク上のファイルでサポートされているデフォルトのSQLiteデータベースを使用していることです。 コンテナを停止して削除すると、このSQLiteファイルはどうなると思いますか？ ファイルが消えます！

コンテナ内のファイルシステムは一時的です。つまり、コンテナが停止すると消えます。 ファイルシステムにデータを書き込むことができ、コンテナーがそれを読み取る必要がある場合にデータを使用できますが、何らかの理由でコンテナーをリサイクルして新しいものと交換する必要がある場合、アプリケーションによってディスクに保存されたデータは永久に失われます。

コンテナアプリケーションの優れた設計戦略は、 ステートレスアプリケーションコンテナを作成することです。 アプリケーションコードがあり、データがないコンテナがある場合、それを破棄して新しいコンテナに問題なく置き換えることができます。コンテナは実際に1回だけになります。これは、更新プログラムの展開を簡素化するという点で大きな成果です。

しかし、もちろん、これは、データをアプリケーションコンテナーの外部のどこかに配置する必要があることを意味します。 ここで、素晴らしいDockerエコシステムが活躍します。 Docker Container Registryには、さまざまなコンテナーイメージが含まれています。 Pythonコンテナイメージについては既に説明しましたが、これはマイクロブログコンテナのベースイメージとして使用します。 さらに、Dockerは、他の多くの言語、データベース、およびDockerレジストリ内の他のサービスのイメージをサポートします。これで十分でない場合、レジストリにより、企業は製品のコンテナーイメージを公開できます。画像。 これは、サードパーティのサービスをインストールする労力が、レジストリで適切なイメージを見つけて、対応する引数を指定したdocker runを使用して起動することに軽減されることを意味します。

そこで、MySQLデータベース用とElasticsearchサービス用の2つの追加コンテナーを作成します。次に、これら2つの新しいコンテナーへのアクセスを可能にする一連のパラメーターでMicroblogコンテナーを起動する長いコマンドラインを実行します。

MySQLコンテナーの追加

他の多くの製品やサービスと同様に、MySQLにはDockerレジストリで利用可能なパブリックコンテナーイメージがあります。 私自身のMicroblogコンテナと同様に、MySQLはdocker run渡される環境変数に依存しています。 これらは、パスワード、データベース名などの設定です。 レジストリに多くのMySQLイメージがあるという事実にもかかわらず、MySQLチームによって公式にサポートされているものを使用することにしました。 MySQLコンテナーのイメージに関する詳細情報は、そのレジストリページhttps://hub.docker.com/r/mysql/mysql-server/で見つけることができます 。

第17章で時間のかかるMySQLチューニングプロセスを覚えているなら、MySQLのデプロイがどれほど簡単かを見て、Dockerに感謝するでしょう。 MySQLサーバーを起動するdocker runとおりです。

 $ docker run --name mysql -d -e MYSQL_RANDOM_ROOT_PASSWORD=yes \ -e MYSQL_DATABASE=microblog -e MYSQL_USER=microblog \ -e MYSQL_PASSWORD=<database-password> \ mysql/mysql-server:5.7 

以上です！ Dockerがインストールされている任意のマシンで、上記のコマンドを実行して、ランダムに生成されたルートパスワード、 microblogと呼ばれるまったく新しいデータベース、およびデータベースへのフルアクセスのための同じ名前と設定を持つユーザーがインストールされたMySQLサーバーを取得できます。 MYSQL_PASSWORD環境MYSQL_PASSWORD値として正しいパスワードを入力する必要があることに注意してください。

アプリケーション側では、Ubuntuでの従来の展開については、MySQLクライアントパッケージを追加する必要があります。 pymysqlを使用します。これをDockerfileに追加できます 。

Dockerfile：pymysqlをDockerfileに追加します。

 # ... RUN venv/bin/pip install gunicorn pymysql # ... 

アプリケーションまたはDockerfileを変更するたびに、コンテナーイメージを再構築する必要があります。

 $ docker build -t microblog:latest . 

これでMicroblogを再び起動できますが、今回はデータベースコンテナーへのリンクを使用して、両方がネットワーク経由で通信できるようにします。

 $ docker run --name microblog -d -p 8000:5000 --rm -e SECRET_KEY=my-secret-key \ -e MAIL_SERVER=smtp.googlemail.com -e MAIL_PORT=587 -e MAIL_USE_TLS=true \ -e MAIL_USERNAME=<your-gmail-username> -e MAIL_PASSWORD=<your-gmail-password> \ --link mysql:dbserver \ -e DATABASE_URL=mysql+pymysql://microblog:<database-password>@dbserver/microblog \ microblog:latest 

--linkパラメーターは、別のコンテナーを使用可能にするようにDockerに指示します。 引数には、コロンで区切られた2つの名前が含まれます。 最初の部分は、通信用のコンテナの名前または識別子です。この場合は、上記で作成したmysqlです。 2番目の部分は、このコンテナーでリンクに使用できるホスト名を定義します。 ここでは、データベースサーバーを表す汎用名としてdbserverを使用します。

2つのコンテナー間の接続が確立されたら、 DATABASE_URL環境変数を設定して、SQLAlchemyが別のコンテナーのMySQLデータベースを使用するように指示できます。 データベースURLは、データベースのホスト名としてdbserverを使用し、データベースおよびユーザー名としてmicroblogを使用し、MySQLの起動時に選択したます。

MySQLコンテナで実験しているときに、データベースへの接続を受け入れる準備ができるまでこのコンテナの起動に数秒かかるという事実に気付きました。 boot.shスクリプトがflask db migrateを実行しようとした直後にMySQLコンテナとアプリケーションコンテナを連続して起動すると、データベースが接続を受け入れる準備ができていないため、クラッシュが発生する可能性があります。 ソリューションの信頼性を高めるため、繰り返しループをboot.shに追加することにしました 。

boot.sh ：データベースへの接続を再試行します。

 #!/bin/sh source venv/bin/activate while true; do flask db upgrade if [[ "$?" == "0" ]]; then break fi echo Upgrade command failed, retrying in 5 secs... sleep 5 done flask translate compile exec gunicorn -b :5000 --access-logfile - --error-logfile - microblog:app 

このループは、 flask db upgradeコマンドの終了コードをチェックし、ゼロに等しくない場合、何か問題が発生したことを意味するため、5秒間一時停止してから再試行します。

Elasticsearchコンテナーの追加

DockerのElasticsearchドキュメントには、2つのノードですぐに使用できる、開発と展開のための単一ノードとしてサービスを実行するオプションが用意されています。次に、単一ノードオプションでdockerを実行し、オープンソースエンジンのみを備えた「oss」イメージを使用します。コンテナは次のコマンドで起動されます。

 $ docker run --name elasticsearch -d -p 9200:9200 -p 9300:9300 --rm \ -e "discovery.type=single-node" \ docker.elastic.co/elasticsearch/elasticsearch-oss:6.1.1 

このコマンドdocker runは、マイクロブログやMySQLで使用したコマンドと多くの共通点がありますが、興味深い違いがいくつかあります。まず、2つのオプション-pがあります。つまり、このコンテナは1つではなく2つのポートでリッスンします。ポート9200と9300は両方とも、ホストコンピューターの同じポートにマップします。

. , , <name>:<tag> . MySQL <account>/<name>:<tag> , Docker. Elasticsearch, , <registry>/<account><name>:<tag> , . , Docker. Elasticsearch docker.elastic.co , Docker.

, Elasticsearch, Microblog, URL Elasticsearch:

 $ docker run --name microblog -d -p 8000:5000 --rm -e SECRET_KEY=my-secret-key \ -e MAIL_SERVER=smtp.googlemail.com -e MAIL_PORT=587 -e MAIL_USE_TLS=true \ -e MAIL_USERNAME=<your-gmail-username> -e MAIL_PASSWORD=<your-gmail-password> \ --link mysql:dbserver \ -e DATABASE_URL=mysql+pymysql://microblog:<database-password>@dbserver/microblog \ --link elasticsearch:elasticsearch \ -e ELASTICSEARCH_URL=http://elasticsearch:9200 \ microblog:latest 

, . , , Elasticsearch .

http://localhost:8000 . , . , , Python:

 $ docker logs microblog 

Docker

, , Docker, , . , Docker, .

Docker, https://hub.docker.com . , , , , .

docker login :

 $ docker login 

, microblog:latest , . Docker, , , MySQL. docker tag :

 $ docker tag microblog:latest <your-docker-registry-account>/microblog:latest 

docker images , , microblog:latest , . .

Docker, docker push :

 $ docker push <your-docker-registry-account>/microblog:latest 

, , Docker , MySQL .

Docker , , Docker. , , 17 Digital Ocean, Linode Amazon Lightsail. Docker .

Amazon Container Service (ECS) , , AWS , .

最後に、Kubernetesなどのプラットフォームを組み合わせたコンテナは、ロードバランシング、スケーリング、セキュリティ管理、ロールバック可能な順次更新を使用して、シンプルなYAMLテキストファイルで複数のコンテナの展開を説明できるため、さらに高いレベルの自動化と利便性を提供します。

ここに 戻る