Web App for Containers + MySQLでコンテナ対応したRailsアプリを作ろう！
•
1 like•2,782 views
Web App for Containers は、アプリスタックのホストに Docker コンテナーを使用するため皆さんが今Linux上で利用しているOSSベースのアプリもアプリスタックごとDockerコンテナ化することでそのまま Web App for Containersで利用することができます。本ウェビナーでは簡単なMySQL + Ruby on Rails アプリ を題材に、アプリをコンテナ化し Web App for Containersにデプロイするまでの一連の流れを解説し、CIツールを使った継続的なデプロイ方法についてご紹介します。今回、AzureのフルマネージドMySQLサービスであるAzure DB for MySQLを利用して完全マネージドな環境でのアプリ実行を実現します。
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Web App for Containers + MySQLでコンテナ対応したRailsアプリを作ろう！
Similar to Web App for Containers + MySQLでコンテナ対応したRailsアプリを作ろう！ (20)
More from Yoichi Kawasaki
More from Yoichi Kawasaki (19)
Recently uploaded
Recently uploaded (16)
Web App for Containers + MySQLでコンテナ対応したRailsアプリを作ろう！
- 1. Web App for Containers + MySQLで コンテナ対応したRailsアプリを作ろう！ Yoichi Kawasaki Azure Technology Solution Professional Asia Intelligent Cloud Global Black Belt Microsoft Corporation Slides for Azure Webinar: Azure PaaS App + DevOps
- 2. アジェンダ • サンプルアプリとその実行環境の紹介 • Web App for ContainersとApp Service on Linux • Azure Database for MySQL/PostgreSQL • アプリをDockerコンテナ化してフルマネージドサービスに移行 • 継続的デリバリー（CD）
- 3. 今日お話しするRailsアプリ と最終的な実行環境について 簡易ブログ、フレームワークはRuby on Rails、データベースはMySQL Container Web App for Containers Rails + Nginx + Puma
- 4. Web App for Containers と App Service on Linux
- 5. コンテナを使う理由？ • アプリケーションのポータビリティ • 必要なものは全てイメージ化してクラウド、オンプレをまたがってコンテナを 移動できる • 起動時間の短縮 • 仮想マシンよりもオーバーヘッドが少なく起動が高速 • 高密度なリソース利用が可能 • 構成が仮想化よりも単純であるため高密度なリソース利用が可能
- 6. Azureのコンテナ関連サービス Azure Container Service Service Fabric App ServiceAzure Container Instance IaaS Low Level PaaS High Level PaaS • Azure Container Service • IaaSベースのサービス、複数のVMを使ってクラスタを構成。Kubernetes, DCOS Docker, Swarmを 使ってコンテナのスケールとオーケストレーションが簡単できるサービス • Azure Container Instance • VMいらずで、シングルコマンドで簡単かつ高速に実行可能なコンテナインスタンス。秒単位課金 • Azure Service Fabric • マイクロサービス向けのオーケストレーターとランタイム。大規模サービス向け • App Service (Web App for Containers + App Service on Linux) • アプリ実行に必要なさまざま機能が用意されたPaaS環境
- 7. Azure App Service - アプリ実行PaaS環境群 • 用途に応じたアプリケーション実行のPaaS環境を提供 • 負荷分散、オートスケール、継続的インテグレーション(CI)、 災害対策(DR)などさまざまな機能を提供
- 8. App Serviceを使う理由？ • フルマネージドなアプリ実行環境 • これまではWindows + IISのマネージド環境 • パッチあてなどUpdate とランタイムの更新は Azureが行う • 高速なプロビジョニング • 数秒でアプリ実行環境が完成 • 柔軟なスケーリング • スケールアップ・スケールアウトも数クリック、オートスケールも可能 • 簡単なデプロイメント • 既存のコードレポジトリ（Git/Github）やCIツール・サービス（Jenkins, VSTS, TravisCI/CircleCIなど） と連携した CI/CD が容易に実現可能
- 10. Web App for Containers App Service on Linux • フルマネージドサービス、Platform-as-a-Service (PaaS) • 柔軟なスケールアップ・ダウン + オートスケール • お客様からの強い要望により実現 • Linux VMで動いているコンテナベースのアプリをターゲット • オンプレからのLift and Shiftがとても容易 2017年9月正式リリース
- 11. Azure App Services on Linux • Web App with built-in images • Node.js, PHP, .NET Core, Rubyなどランタイムス タックを選択してアプリケーションをデプロイ • Windows Web App と同じ方法で利用可能 https://github.com/azure-app-service
- 12. Web App for Containers • Bring Your Own Container • アプリケーション入りの皆さんのカスタムイメージを デプロイして実行する イメージのソース Azure Container Registry Docker Hub プライベートレジストリ
- 15. Azure Database for PostgreSQL Azure Database for MySQL • フルマネージドサービス, PaaS • 可用性担保のためのレプリカ、ストレージ費用は追加不要 • インスタンス チューニングではなく 必要なスループット プランを必要なときに選択 • ダウンタイム無しでスケールアップ、スケールダウンも自在 • 自動バックアップ、 ポイントインタイムリカバリ（PITR）可能 （ 35日間） • 常時暗号化でバックアップも運用 DB も保護 • 既存のドライバ、ライブラリ、ツールと完全互換 使い慣れたツール、アプリケーションでからすぐに利用可能 （マイクロソフト製のツールやドライバなどは不要） MySQL PostgreSQL New! Public Preview MySQL 5.6/5.7 (Community Version) PostgreSQL 9.5/9.6 (Community Version)
- 16. AZURE DATABASE FOR POSTGRESQL AND MYSQL REGION AVAILABILITY TODAY West US, North Central US, East US, East US2, South Central US, West Europe, North Europe, Japan West, Japan East, East Asia, SE Asia, West India, Central India More coming soon! 13 Azure regions available today
- 17. MySQL / PostrgreSQL サービスの構成基盤 • Azure SQL Database と共通基盤 • これまでの運用実績、ノウハウをフィードバック「枯れた」基盤で運用 • Virtual Machine 上ではなく、”Service Fabric” 上に実装 https://azure.microsoft.com/ja-jp/services/service-fabric/ PowerBI,AppServices,DataFactory, Analytics,ML,Cognitive,Bot… Global Azure with 38 Regions Azure Compute SQL Data Warehouse Azure Storage SQL Database MySQLPREVIEW PostgreSQLPREVIEW Flexible: On-demand scaling, Resource governance Trusted: HA/DR, Backup/Restore, Security, Audit, Isolation Intelligent: Advisors, Tuning, Monitoring Database Services Platform Service Fabric
- 18. サービスの概念と接続イメージ Azure リージョン Azure Resource Manager Application Postgres Client Database Tools (Pgadmin, psql) Postgres Client Database Tools (MySQL Workbench, mysql Client) MySQL Client Azure Database Mgmt Service Application MySQL Client REST API Azureポータ ル カスタム管理 アプリAzure CLI • 論理 DB : “インスタンス” ではない • 1 対多のデータベースを作成可能 • リソースはすべて同じ論理サーバ内の DB 間で共有 • Database の “エンドポイント” • 接続制御はファイアウォールの ルールベースで実施
- 19. ダウンタイム無しでスケーリング可能 Azure リージョン Database Server サーバーマネジメント Azure Database Mgmt Service Azure Resource Manager REST API Azure ポータル Custom Mgt. ApplicationsAzure CLI server=myserver.<mysql/postgres>.database.azure.com IP1:5432 or 3306 retry • いったん接続が切れても内部ゲートウェイでリトライ してくれるのでアプリケーションは切断の影響を受け にくい • さらに慎重を期すならば、長時間トランザクションを 避ける実装にすることがおすすめ (トランザクションは接続オブジェクトに紐づくため) Gateway
- 20. セキュリティの仕組み データ保護 • 標準でデータベースと バックアップ データを 暗号化 (AES 256) アクセス管理 • 規定SSL 接続 • サーバー ファイアウォール • （IPホワイトリスト方式） ID 管理 • PostgreSQL / MySQL ネイティブ認証
- 21. その他運用面でのメリット • 自動的にパッチ適用で運用の心配を減らす • メトリック監視とアラート機能を提供 • サーバーログは最大7日分まで保存（ポータル、Rest API, Azure CLIで確認可能） • 最大35日分のバックアップを保持でポイントインタ イムリカバリ可能 • サーバーパラメータの設定も可能
- 22. サービス帯とパフォーマンス 22 Service Tier 想定ユースケース 低めのワークロード IOPSが可変でも問題ないケース 全体のスループットを重視し IOとCPUバランスを取りたい ケース 高いスループット、 IOPSを実現したいケース Compute Units（CU） 50, 100 100, 200,400,800 ?? Storage (included) 50GB Magnetic Media 125GB Remote SSD ?? IOPS (included) Variable 375 ?? 追加オプション 99.99% SLA (今後) | フルマネージド| 高可用性 | オンラインパフォーマンス変更 Storage Scale up to 1 TB Scale up to 1 TB ?? IOPS NA Scales 3:1 (IOPS:GB) ?? Public Preview ※ これらは Public Preview 版の情報であり、今後変更になる可能性があります
- 24. サンプルアプリとその移行イメージ サンプルアプリ • Rails Scaffoldingで生成された簡易ブログアプリでデータベースにMySQLを使用 • フレームワークはRuby on Rails、WebサーバにNginx、RackサーバにPumaで構成 Container Web App for Containers Rails + Nginx + Puma VM Rails + Nginx + Puma MySQL on VM サンプルコード: https://github.com/yokawasa/ci-demo-rails-app
- 25. フルマネージド化対応までの流れ 1. MySQL接続部をAzure DB for MySQLに対応 2. アプリをDockerコンテナイメージにパッケージ化 3. コンテナレジストリに作成したコンテナイメージを push（Docker Hub / Azure Container Registry) 4. Web App for Container の プロビジョニング ＋ コンテナイメージのデプロイメント
- 26. Azure DB for MySQLの作成 Azureポータル、Azure CLI、REST API経由で作成可能 ここではAzure CLIでの作成方法をご紹介 DBアカウントの作成 yoichikamysql (サービス帯: Basic, リージョン: 西日本, adminユーザ: yoichika) az mysql server create --name yoichikamysql --resource-group myrgroup --location japanwest --admin-user yoichika --admin-password *** --performance-tier Basic --compute-units 50 → サーバ名: yoichikamysql.mysql.database.azure.com
- 27. Azure DB for MySQLの設定 ファイアウォールの設定（ここでは全てのIPレンジを許可） az mysql server firewall-rule create --resource-group myrgroup --server yoichikamysql --name AllowFullRangeIP --start-ip-address 0.0.0.0 --end-ip-address 255.255.255.255 mysqlコマンドでテストアクセス mysql -u yoichika@yoichikamysql -p -h yoichikamysql.mysql.database.azure.com ssl-enforcement パラメーターを無効化（以降のアプリテスト簡略化のため・・・） az mysql server update --resource-group mygroup --name yoichikamysql --ssl-enforcement Disabled https://docs.microsoft.com/en-us/cli/azure/mysql
- 28. アプリのDB接続設定を修正して RailsコマンドでDBテーブル新規作成 Rails設定ファイルのMySQL接続情報をAzure DB for MySQLに変更 → config/database.yml Railsコマンドでアプリ用データベースとテーブル作成
- 30. アプリのパッケージ化 - 1/2 Dockerfileの作成（これに尽きる） • Dockerコンテナーの構成内容をまとめて記述するファイル https://blogs.msdn.microsoft.com/waws/2017/09/08/things-you-should-know-web-apps-and-linux/ Web App用カスタムコンテナのための設定ポイント 外部公開用ポートの自動バインド 外部公開可能なポートは１つのみ。ポートは自動で検知されコンテナにバインドされる。 WEBSITES_PORT環境変数で明示的に指定可 SSHの設定 Azureポータル内のクライアントからのみコンテナイメージにSSHログインが可能。rootユーザーパスワードは“Docker!”, ポートは2222 https://docs.microsoft.com/en-us/azure/app-service/containers/app-service-linux-ssh-support 永続化データと/homeディレクトリ WEBSITES_ENABLE_APP_SERVICE_STORAGEをtrueで/homeディレクトリはストレージにマウントされる この場合、ビルド段階で/homeディレクトリにコピーされたデータは削除され、ストレージマウントが行われる
- 31. FROM ruby:2.4.1 MAINTAINER Yoichi Kawasaki yoichi.kawasaki@microsoft.com RUN apt-get update -qq && apt-get install -y --no-install- recommends vim openssh-server && apt-get install -y build-essential libmysqlclient-dev nodejs && apt-get install -y nginx WORKDIR /myapp ## Setup all the configfiles COPY rails-app/bin/init_container.sh /bin/init_container.sh RUN chmod 777 /bin/init_container.sh && echo "root:Docker!" | chpasswd && rm -f /etc/nginx/conf.d/* COPY railsapp/config/nginx.conf /etc/nginx/conf.d/myapp.conf COPY railsapp/config/sshd_config /etc/ssh/sshd_config COPY railsapp /myapp ## Install for Rails app RUN gem install bundler –pre && bundle install --path /myapp/vendor/bundle EXPOSE 8080 2222 ENV PORT 8080 ENV WEBSITE_ROLE_INSTANCE_ID localRoleInstance ENV WEBSITE_INSTANCE_ID localInstance #Start Server ENTRYPOINT ["/bin/init_container.sh"] Dockerfile init_contailer.sh Web AppへのSSHログインのための設定 永続化ディレクトリ（/home）にログ出力
- 32. アプリのパッケージ化 - 2/2 コンテナをビルドする (image-name:tag=railsapp:0.0.1) コンテナをローカルで走らせてテスト [注意] 環境変数でMySQL接続情報をセットが必要
- 33. DockerHubにイメージをPUSH Docker HubにPUSH (image-name:tag=railsapp:0.0.1) Docker Hubにイメージが PUSHされていることを確認 <docker-id>/<imagename>:<tag> = yoichikawasaki/railsapp:0.0.1
- 35. Web App for Containerプロビジョニング Azure CLIによる設定 https://docs.microsoft.com/en-us/azure/app-service/containers/tutorial-custom-docker-image Web App for Containerの作成(プロビジョニング時にコンテナを指定) # App Settingsに環境変数をセット (--settingsのパラメータにスペース区切りで複数設定可）
- 36. 継続的デリバリー（CD）
- 37. AzureでのCDオプション Web AppのWebhookとコンテナレジストリ連携 • Docker Hub/Azure Container RegistryにイメージPUSHでWebhookキックされてWeb Appのコンテナ入れ替える、お手軽な手法 • https://docs.microsoft.com/en-us/azure/app-service/containers/app-service-linux-ci-cd 自動化を支えるCI/CDツール群 • Visual Studio Team Services • Jenkins • TravisCI / CircleCI
- 39. CircleCI – パイプライン設定内容 パイプライン処理で必要な パッケージをインストール コンテナイメージのビルド イメージのテスト Docker Hubにイメージ プッシュ Web Appのベースコンテナ を新しいイメージに設定変更 設定ファイル: https://github.com/yokawasa/ci-demo-rails-app/blob/master/.circleci/config.yml
- 40. Thank you
- 42. APPENDIX
- 43. Rails Scaffoldでアプリ雛形作成 - 1/2 Scaffoldアプリ雛形作成 config/database.ymlの編集
- 44. Rails Scaffoldでアプリ雛形作成 - 2/2 Scaffoldアプリに必要なテーブルの作成 rails serverを起動してテスト実行し、http://localhost:3000/articlesにアクセス bundle exec rails server curl http://localhost:3000/articles
- 45. App Service Jenkins Plugins https://azure.microsoft.com/en-us/blog/annoucing-jenkins-deploy-to-azure-app- service-plugin-and-new-managed-disk-support-for-azure-storage-plugin/
Editor's Notes
- Web App for Container は、アプリスタックのホストに Docker コンテナーを使用しており、皆さんが今Linux上で利用しているOSSベースのアプリもアプリスタックごとDockerコンテナ化することでそのまま Web App for Container で利用することができます。 本ウェビナーでは アプリ実行環境にWebAppForContainer、MySQLにAzureのフルマネージドMySQLサービスであるAzure DB for MySQLを利用しますのでこちらのサービスの説明をいたします。 また、簡単なMySQL + Ruby on Rails アプリ を題材に、アプリをコンテナ化しフルマネージド化するための一連の流れを解説します。 そして最後にCIサービスを使った継続的デリバリ方法についてご紹介します。
- Dockerのポータビリティとは同じCPUアーキテクチャ（Intel x86_64）で動く同じOS上であれば、Dockerイメージをそのままポータブルに利用可能 ホストLinuxの種類が異なる環境で利用する際には、思わぬ問題が発生する恐れがある https://www.school.ctc-g.co.jp/columns/nakai/nakai43.html 一方、異なるCPUやOSの場合でも、OS固有の機能（たとえばパッケージインストールなど）を使わずにDockerファイルをうまく書いてあれば、同じDockerfileで同様のコンテナーを再現できる。 起動時間の短縮 Dockerを実行するホスト上で他のアプリケーションと同様のプロセス単位で管理されるため、ハイパーバイザー型の仮想化マシンでいうOSブート処理が必要ありません 構成が仮想化よりも単純で、リソース消費量が少ないため、高密度化が可能である
- ACI： ACSが予測可能な処理のスケーリングに向いているのに対して、ACIは特定処理のバーストシナリオにおいて高速起動・実行することに向いています Aci-connector-k8sというコネクタがあるのでACIをkubernatesの仮想ノードとして利用可能、よって同じK8s (Kubernetes) クラスター内ではVMとACIインスタンスを同時に利用できますので、両社の長所を生かせます。高速なバースト対応にACIを使える一方で、より予測可能なスケーリングのためにVMを使えます ServiceFabric マイクロサービス向けのオーケストレーターとランタイムを提供するPaaSサービスで、HA、スケール、並列処理などマイクロサービスなアプリケーションを開発が容易にできるPaaSであり、そのためのアプリケーションフレームワークも提供されています 大規模スケールについて 1つのVM Scale Setsにつき1000個のVMを持てる,よって最大 1000 台の VM インスタンスにスケーリングできる。一方ACSクラスタはエージェントノードは100までスケール Azure Service Fabricのノードタイプの数に制限はありません。そのためVM Scale Setsのリミテーションに従うということになります。 https://docs.microsoft.com/ja-jp/azure/service-fabric/service-fabric-common-questions#cluster-setup-and-management [note] 実行に必要な VM Service Fabric は 5 台、Container Service は 2 台の VM が必要 高可用性を考えると Container Service は更に必要
- Mobile Apps = モバイル アプリのバックエンドをホストするためのサービス API Apps= RESTful API をホストするためのサービス Logic Apps = ビジネス プロセスの自動化し、さまざまなクラウドシステムのデータを統合するためのアクセスと使用 を自動化するためのサービス
- フルマネージド これまでの環境では：.NET／PHP／Node.js／Python／JavaといったラインタイムのWebアプリケーションの稼働が可能（Windows上）
- 一瞬過去中国に存在していた My SQL サービスとは別。別アーキテクチャ
- コンテナイメージをレジストリにPUSHする Web App For Containerではそのイメージのソースを指定する イメージソースの選択肢として、DockerHub以外に、AzureのマネージドのプライベートレジストリであるACR、もしくはそれ以外のプライベートレジストリも指定可能
- Azure Container Registry The new preview ACR tier, managed registries, is available in 3 options: Basic, Standard, and Premium AAD authentication for repositories, Delete operations, Webhook support
- 一瞬過去中国に存在していた My SQL サービスとは別。別アーキテクチャ 2017/05 Public preview release
- AzureDB for MYSQL/POSTGRESQLはSQLDBおよびSQLDWサービスと同様のデータベース基盤Database Service Platform（DBSP）の上に構築されているます。 DBSPはSeervice Fabricをベースに組み込みHA、バックアップ/リストア・サービス、リソース・ガバナンス、監視とパフォーマンス・チューニング、およびアドバイザ機能を備えた各データベースの完全分離などの機能を提供します。現在、このプラットフォームが拡張され、2つのデータベース管理サービス（MySQLとPostgreSQL）が追加されています。
- 1. 1つ以上のデータベースで構成される論理DB 2. 論理的エンドポイントでデータベースに接続 3. MySQL/PostgreSQLサービスは、Azure Resource Managementサービス（ARM）を介して公開、REST APIを通じて、サーバーとデータベースのプロビジョニングと管理を可能にする。これらのARM APIを使用して、サービスとのすべての管理対話が可能。 MySQL/PostgreSQLサービスは、それぞれCommunity Version / ネイティブ PostgreSQLの認証とセキュリティモデルをサポートしています。 データベース管理ツールと開発ツールは、みなさんがお使いのMySQL/PostgreSQLプロトコルを介して接続することが可能 データベースエンジンは：コミュニティバージョンのMySQLとPostgreSQLデータベースエンジンを使用している MySQL: Community Version: 5.6/5.7 PostgreSQL: Native PostgreSQL: 9.5/9.6
- - 高可用性を実現するため、複数レプリカによる冗長性を備えている ダウンタイムなしでスケーリングが可能な仕組み：内部GWがリトライでアプリは切断の影響をうけにく（Failover、Patch、スケーリングで新規ストレージ展開） - ただしトランザクションについては接続オブジェクトに紐づいているため影響をうけてします。できる限りトランザクション間隔を細かくして実行いただくことを推奨 クラウド上に配置されたデータベースをサービス (Software as a Service : SaaS) として提供しており、高可用性を実現するため、複数レプリカによる冗長性を備えています。また、高可用性を維持していくために、Reconfiguration (リコンフィグレーション) が内部的に行われています。 HA（高可用性）モデルは、ノードレベルの中断の場合にデータベースをレプリカにフェイルオーバーする組み込みのメカニズムに基づいています。これは、ハードウェア障害のために発生する可能性がありますが、OSまたはPostgreSQLエンジンへのサービス展開またはパッチへの応答としても発生します。 PostgreSQLに加えられた変更は、トランザクションのコンテキストで常に発生し、トランザクションがコミットされる前に、セカンダリストレージまたは別のデータベースのレプリカに同期して記録されます。ノードレベルの割り込みが発生すると、データベースサーバーは自動的に別のノードで実行されているレプリカに切り替えます。アクティブな接続はすべて破棄され、実行中のトランザクションはコミットされません。 PostgreSQLデータベースアプリケーションは、削除された接続や失敗したトランザクションを検出して再試行することが重要です。アプリケーションが接続を再試行すると、プライマリ・データベースとして引き継ぐレプリカにリダイレクトされます。新しいレプリカへのカットオーバは、平均して30秒以上です。
- all data at rest (database files, logs, backups) are encrypted by default with service-managed keys
- Compute Unit とは？ = Azure Database for MySQL/PostgreSQLサーバーで使用できることが保証される CPU 処理スループットの測定値 ( CPU とメモリ リソースを組み合わせた測定値 ) - 目安：100 CU = 1 core - ただし、Standard 価格レベルで事前構成されたメモリ量は、Basic 価格レベルで構成されているメモリ量の 2 倍 IOPSについて - BasicはIOPS保証なし - StandardのIOPS: GB あたり 3 IOPS 固定。つまり125GB = 375IOPS(保証) - 最大 256 KB の IO サイズ保証 - IOPS は固定の 3:1 の割合で最大ストレージ サイズに比例してスケーリングします Standard CUについては 近日1600、2000提供予定 Premium について - 今年を目処に実現 - Storage: Local SSD 機能面 VNET Service Tunneling More performance and scaling options with premium service tier and larger storage sizes Migration tooling Readable Replicas Disaster Recovery Much more….
- Rails scaffolding is a quick way to generate some of the major pieces of an application. If you want to create the models, views, and controllers for a new resource in a single operation, scaffolding is the tool for the job.
- コンテナ イメージを作成するための指示が記述されている
- コンテナ イメージを作成するための指示が記述されている
- コンテナ イメージを作成するための指示が記述されている
- https://blogs.msdn.microsoft.com/waws/2017/09/08/things-you-should-know-web-apps-and-linux/#OnePort https://blogs.msdn.microsoft.com/waws/2017/09/08/things-you-should-know-web-apps-and-linux/#HomeOverwrite
- コンテナ イメージを作成するための指示が記述されている
- コンテナ イメージを作成するための指示が記述されている
- https://docs.microsoft.com/en-us/azure/app-service/containers/tutorial-custom-docker-image
- App ServicesはまさにDevOpsを前提とした便利な機能を提供している この継続的デリバリを含むCI/CDというのが開発・リリーススピードの維持、効率化にとても重要になってきます。 継続的デリバリ: コード変更→自動ビルド、テスト、ステージング環境プッシュで本番デプロイ準備の整った状態にすること
- VSTS: CI/CD, vesion管理, 自動build, テスト管理、リリースマネジメント Github, DockerHub, Azure Functions連携パターン https://lee-dale.net/2017/03/31/ci-with-azure-web-apps-for-linux-github-dockerhub-and-azure-functions/
- https://docs.microsoft.com/en-us/azure/app-service/containers/tutorial-custom-docker-image