• CI/CD の推進について ~ Azure Data Factory ~

    こんにちは。 Azure Cloud Solution Architect の秋山です。 今回は推進している CI/CD の取り組みについて、 Azure Data Factory(以下、ADF) を取り上げて紹介します。 ADF そのものの紹介については今回は触れません。少し古いですが以前ハンズオンしたときの記事がありますので、参考にしてください。 Azure Data Factory 入門ハンズオンの資料を公開します

    なぜ CI/CD を推進しているのか

    みなさんは時間を持て余してますか? 私はいつももっと欲しいと思うことが多いです。 もし時間が袋詰めで売ってたら買いたいくらいです。

    そんな有限で平等なリソースである時間を有効活用するためにも、 CI/CD の推進は重要です。

    開発/検証/本番環境の3環境があるプロジェクトにおいて、開発環境より後述の環境に対しては、開発環境と同じ成果物を自動的にデプロイしたい、というニーズがあります。 その背景は、開発環境で修正したバグが検証/本番環境で発生してしまうといったつまらない問題を回避したい、というものです。 もしも人が3環境を手動でデプロイしていると、こういったつまらない問題がかなりの頻度で発生してしまいます。 人はミスをする生き物なので、避けがたい問題に時間を費やすのではなく、価値を生み出すことに時間を割きたいものです。

    Azure Data Factory の CI/CD 構築例

    構成イメージとしては以下のとおりです。

    Azure Data Factory - CI/CD by Azure DevOps
    • 開発者は開発環境の ADF の開発ポータルを操作して開発します
    • 開発者は開発の区切りで publish を行います
    • publish を行うと、 ARM Template が Azure Repos に Commit されます
    • Commit によって Azure Pipelines がトリガーされると、ARM Template を使って検証/本番環境の ADF にリソースをデプロイします
    • 開発者は環境差異を ARM Template Parameter で管理して適宜更新します

    参考: https://docs.microsoft.com/ja-jp/azure/data-factory/continuous-integration-deployment

    ...
  • Azure Web App で静的サイトをホスティングした事例

    こんにちは、Azure系エンジニアの秋山です。 今回は Azure Web App で静的サイトをホスティングした事例についてご紹介します。

    前提

    • サイトジェネレータ Jekyll を利用
    • 一部 PHP を利用
    • サイトを更新するユーザーは Jekyll を知らない、意識させたくない

    構成

    構成は単純に Web App を Web サイトとして使ったのみです。 静的ファイルのみならば、 Web サイトの PaaS である Web App を使う必要はないのですが、一部で PHP を利用する要件があったことから Web App を採用しています。

    デプロイフロー

    deploy-flow

    順を追って説明します。

    今回、CMS として CloudCannon というサービスを利用します。 このサービスを使うことで Jekyll を意識せず、エンジニアでなくともページの更新や微調整を行うことができます。(手順1)

    CloudCannon では GitHub と連携できるようになっています。 CloudCannon 上でリアルタイムに jekyll build されたコンテンツをプレビューしつつ、各ページを更新することが可能です。(手順2)

    ...
  • Azureエンジニアから見たDockerを取り巻くDevOpsサービスのまとめ

    Azure系エンジニアの秋山です。

    最近 Azure で Webサービスを Docker で動かす PaaS の Web App for Containers が GA となり、プレビューの頃から使っていた 立場としては嬉しい限りです。

    今回は Production での導入が広がっていきそうな Docker を取り巻く Dev/Ops のサービスをまとめてみます。

    Docker を取り巻く要素

    Docker を使って Dev/Ops を構成するためには、

    • Dockerfile を含めたリポジトリを管理するソースコード管理システム(VCS)
    • Docker イメージをビルドするビルドシステム
    • ビルドした Docker イメージをホスティングするホスティングサービス

    の3つが必要です。

    図に表すと以下のとおりです。

    docker-devops-service

    それぞれのサービスのポイントを書いてみます。

    ソースコード管理

    Visual Studio Team Service

    • Git で PullRequest ベースでの開発が可
    • ライセンスが MSDN サブスクリプションに付いてくるため、既に持っていれば導入しやすい
    • Scrum やアジャイルに沿ったプロジェクト管理が可

    GitHub

    • Git で PullRequest ベースでの開発が可
    • 使い慣れたエンジニアが多い(特にWeb系)

    GitLab

    • Git で PullRequest ベースでの開発が可
    • Freeプランがある
    • SaaS を利用できないポリシーに対応可

    ビルド

    Visual Studio Team Service

    • Azure と連携しやすい
    • ビルド時間課金

    CircleCI

    • 予約ホスト課金
    • 2.0 では Docker ビルドでキャッシュを使えるため、高速化の余地がある
    • 汎用ビルドのため導入にひと手間必要

    Docker Hub

    • GitHub と連携しやすい
    • ビルドがDocker専用のため、導入が簡単

    Jenkins

    • SaaS を利用できないポリシーに対応可
    • 他のビルドと共用できる

    ホスティング

    Azure Container Registry

    • Azure の他のサービスと連携しやすい
    • Azure と請求がまとまる

    Docker Hub

    • ビルドとセットでついてくる

    Docker Registry

    • SaaS を利用できないポリシーに対応可

    最後に

    いかがだったでしょうか。 今回挙げた以外にもさまざまなサービスがあります。 ISAO ではこれらを利用し、Azure 上の Docker で LAMP 環境へ移行支援 を行っております。 ご興味ありましたら以下のバナーからお問合せください。

    ...