Kubernetes FullstackアプリケーションのHerokuコンテナへの変換

過去数年間、GoogleのKubernetesプロジェクトは巨大な話題を生み出しました.プロジェクトは成長して、クラウドインフラストラクチャ世界のタイタンに発展しました.
それは素晴らしいプロジェクトであり、多くの目的を果たす一方、それは複雑な獣のままです.主要なクラウドプロバイダーからの管理されたKubernetesサービスでさえ、チームはプラグインとパラダイムシフトの拡大しているコスモスを使用している複雑で、織り込まれた建築を維持しなければなりません.その柔軟性に固有のそのような複雑さで、Kubernetesは、この多様なオーケストレーション生態系を実装して、維持して、アップグレードして、動かすために、それ自身のセットの技術を必要とします.

PAAのシンプルさ

これらの集中的、スキルベースの要件は、いくつかのビジネスモデルに適している可能性があります.しかし、サーバーとセキュリティを管理するのではなく、アプリケーションを構築するのに時間を費やしたいなら、あなたはKubernetesよりむしろサービスとしてプラットホームを考慮したいかもしれません.これらのプロバイダは、インフラストラクチャ、セキュリティ、観測性、および環境の全体的な幸福を維持するので、ビジネスに重要なアプリケーションに焦点を当てることができます.
Kubernetesの描画の1つは、均一な環境経験を提供するその能力です.Kubernetes内に収まるように構築されたアプリケーションは、デザインによって移植性があり、自然界において一時的であり、あらゆるコンテナ駆動型の世界に住むことができ、インフラストラクチャに不可知論的である Twelve Factor Apps アプリケーションを構築する上でより多くのガイドライン).したがって、アプリケーションチームがキュレーションされたPAAを支持するKubernetes管理インフラストラクチャの複雑さの背後に残したかったならば、それはどのように見えるでしょうか?
今日、我々はこの単純なを見ます Kubernetes driven Flask application . 我々はどのように実行し、その要件を学び、どのようにHerokuに変換することができますを探る.

アプリケーションデザイン

このアプリケーションは、Postgresデータベースから俳優のリストをプルし、Webサイト上に表示される単純なフラスコフロントエンドです.あなたが見ることができるように、インフラストラクチャを監視、ログ、サーブ、一般的に時間を提供するアプリケーション自体よりも多くのコンポーネントを確認できます.
Kubernetesでアプリケーションを配備するには、あらかじめ必要なインフラコンポーネント、アプリケーション自体のいくつかのYAML、およびデータベースのヘルムグラフが必要です.

GitLab CI/CD

Ambassador Edge Stack

LinkerD Service Mesh

FluentD Log Collector

Elasticsearch Document Database

Certificate Generation

Ingress Definition

Exposed Ports & Application Deployment

PostgreSQL Helm Customizations

And finally the application itself

必要な手順の多くは、アプリケーションをサービスを取得するだけです.Herokuでの同等の要件を見てみましょう.

PAAベンダーがあなたのためにテクノロジー決定をしたので、あなたはそのベンダーの決定と意見を遵守しなければなりません.しかし、お返しに、あなたは箱から働く堅く統合したサービス提供を得ます.何前に研究メッシュとサービスメッシュの実装とログのエクスポートはわずか数分といくつかのコマンドに削減されていた.
Herokuで同じアプリケーションを展開するには、次の2つの手順が必要です the database and the application.
では、このアプリケーションをKubernetesからHerokuに変換する方法を見てみましょう.次の4つの手順を見ます.

インフラを設定する

アプリケーションを変換

アプリケーションの配備

アプリを更新

インフラストラクチャの設定

我々は、プロンプトで操作性を保証するのに必要なKubernetesの多くのコンポーネントを見ました.

ダウンロードバイナリをダウンロードします.

Kubectlを妥当なクラスタに到達できます.

'Kubectlの適用https://dependency/spec.yaml ' またはバイナリを使用してリソースを作成します.

適切なセキュリティコンテキストで配備が完了したことを確認し、必要に応じて機能します.

Herokuの要件は、はるかに簡単です:アカウントを作成し、ダウンロードしてください heroku cli, and you're done! PAAへの大きな描画は、バリデーションとインストール(あなたがKubernetesであなた自身をしなければならなかったすべてのステップ)がすでにあなたのためにされたということです.
これらの手順は、TLSやトラフィック管理、スケーリング、観測性、および再現性などのいずれかの環境でアプリケーションのコアインフラストラクチャサービスを提供します.

アプリケーションの変換

我々はどのように環境のサンプルアプリケーションを探して、我々はどのように我々はアプリケーションを微調整する必要があることを確認することができます現在のPAAホームで動作するように設立しました.コンポーネントの多くが私たちのために実装されているため、アプリケーションを展開する前にいくつかの必要な変換があります.
これらの手順では、アプリケーションをコンテナとして展開し、アプリケーションのログをstdOUTに表示し、実行時にコンテナにリモートでログインし、インフラストラクチャからアプリケーションのパラメーターをカスタマイズできます.
まず、Dockerfileを変更しなければなりません.init timeでアプリケーションを定義しているKubernetes Dockerfileの場合は、以下のようにして設計しました.

    FROM python:3
    WORKDIR /usr/src/app
    COPY requirements.txt ./
    RUN pip install --no-cache-dir -r requirements.txt
    RUN touch /tmp/healthy && echo "healthy" >> /tmp/healthy && cat /tmp/healthy
    ENV FLASK_ENV=development
    ENV FLASK_APP=myapp.py
    COPY myapp.py .
    CMD [ "flask", "run", "--host=0.0.0.0" ]

イメージは単純です:維持されたベースイメージを使用して、作業ディレクトリを設定し、Pythonの要件を追加し、デフォルトの環境変数を設定し、アプリケーションコードを追加し、サーバーを起動します.
後のステップでは、このDockerFileを使用してアプリケーションを構築するには、Dockerのレジストリにプッシュし、Kubernetesは、アプリケーションを起動するには、ローカルサーバーに画像をプルしている.
Herokuでは、Python固有のベースイメージを使用することにより、Herokuのコンテナ管理インターフェイスにいくつかのパッケージを追加する必要があります.新しいdockerfileは次のようになります.

    FROM python:3
    WORKDIR /usr/src/app
    COPY requirements.txt ./
    RUN pip install --no-cache-dir -r requirements.txt
    RUN apt-get update && \
        apt-get install -y \
        curl \
        openssh-server
    ADD ./.profile.d /app/.profile.d
    RUN rm /bin/sh && ln -s /bin/bash /bin/sh
    RUN echo "healthy" >> /tmp/healthy && \
        cat /tmp/healthy
    ENV FLASK_ENV=development
    ENV FLASK_APP=myapp.py
    COPY myapp.py .
    CMD python3 myapp.py

ここでは、以前と同じイメージを定義しています.

まず最初に、我々は我々のイメージにcurlとsshを加えるインストールの一連の新しいaptを得ます.また、SSH環境を定義するためにスクリプトを追加しました.

[ -z "$SSH_CLIENT" ] && source <(curl --fail --retry 3 -sSL "$HEROKU_EXEC_URL")

そして/bin/bashを/bin/shにリンクしてデフォルトのシェルを宣言しなければなりません.

次に、myAppでフラスコランタイムパラメータを指定することでイメージをインスタンス化する方法を変更する必要があります.PHYファイルは、アプリケーションがかつて配備されたトラフィックを取ることができるようにHeroku定義の環境変数を使用します.

if __name__ == "__main__":
    port = int(os.getenv("PORT", 5000))
    app.run(debug=True, host='0.0.0.0', port=port)

最後の考慮はデータベースです.Kubernetesで、我々はホストにその資金供給能力を利用することができます clustered or replicated databases 破損やノードの失敗から保護する.私たちは Helm chart , ゼロからデータベースアーキテクチャを設計するか、我々のデータベースのために外部ホスティング解決を使用してください.
ただし、ホストサービスを使用する場合には必要ありません.Herokuでは、我々は単に我々のダッシュボードを介してホストデータベースを追加する必要があります.複製と弾力性は、管理するプロバイダの懸念になります.
(データベース実装では、レプリケーションとレジリアンスはテスト済みバックアップの代わりにはなりません!常にバックアップしてコアデータを検証します).
これにより、我々のアプリケーションコンテナイメージとデータベースを準備する準備が整いました.

アプリケーションの実行

コアインフラストラクチャがインストールされていると仮定すると、我々のクラスタのプロビジョニングされたデータベースと、サービスのアカウントに関連付けられた適切なロールベースのアクセスコントロール(RBAC)の構成を使用すると、アプリケーションの展開に集中できます.
私たちの例で定義された明示的なCI/CDパイプラインはありません.ですから、アプリケーションをKubernetesに手動で配備するには、Kubectlバイナリを使って以下のようにしなければなりません:

docker login
docker build -t myorg/myapp:0.0.1 -t myorg/myapp:latest . 
docker push myorg/myapp:0.0.1; docker push myorg/myapp:latest
kubectl apply -f ./spec/

我々が見ることができるように、一旦我々がコア基盤を配備して、YAMLを検証するならば、我々のKubernetesクラスタにコードを手動で転がすのは難しくありません.
Herokuの展開スキームを見ることによって、私たちにはそれらのAPIと対話することができる独自のカスタムバイナリがあります.

heroku login
heroku container:login
heroku container:push web -a myapp
heroku container:release web -a myapp

ここでは、我々は、それが主に同じリリースのマニュアルリリースrigorであるけれども、我々自身のタグ付けとリリース機能を使用するよりむしろ我々のアプリケーションのHerokuのタグ付けと配備を信用します.
いずれかのプラットフォームに組み込まれた配備とリリースパイプラインを呼び出すことは、すべてこの努力を完全に難破させるかもしれませんしかし、それはまた、どちらかの環境で設計、構築、維持されなければならない.
ここでは、両方の環境でアプリケーションを展開するためのプロセスを定義しました.

アプリケーションの更新

既存のアプリケーションをKubernetesに配備する場合、適用するのではなく、別のコマンドを使用します.

docker build -t myorg/myapp:0.0.2 -t myorg/myapp:latest . 
kubectl rollout deployment/myapp -n myapp --record --image=myapp:0.0.2

Herokuでは、単に同じプロセスに従ってください.

heroku container:push web -a myapp
heroku container:release web -a myapp

この最後の手順では、アプリケーションを環境に繰り返し配備するプロセスがあります.

結論

シェイクスピアは「他の名前のバラは甘い香りがする」と書いた同様に我々のアプリケーションは、任意のコンテナ化環境では、capuletやモンタギューと同じように動作します.
我々の安っぽいアナロジーの外で、我々は単純なアプリケーションが複雑で高度にカスタマイズ可能なKubernetes環境で動くことを必要とするものを調査しました、Heroku、我々の管理された基盤プロバイダーからの同じレベルの機能を得るために必要であるものと同様に.結局、両方とも展開して、実行するのが簡単でした、しかし、Herokuは始まるためにその必要条件で非常により少ないことを証明しました.