CI CD

前回の記事（2021年版）から、以下の内容でアップデートしました。 Docker Engine 24.0 BuildKit レイヤーキャッシュ（Registry cache） タグによるバージョン付け 注意：Self Hosted GitLab RunnerでのDockerデーモンを使ったイメージビルドは推奨しません DinDでのビルドのため、ホストOSのroot権限が取得可能な、コンテナの特権実行（--privileged）、またはDockerソケットのマウント（DooD）が要求されます。 GitLab.comのShared Runnerは使い捨てのGCPインスタンスで提供されるため、コンテナブレイクアウト等によりホストのroot権限が取得されても、 Dockerエンジンのホストである仮想マシンごと破棄されますが、そのような工夫をしていないRunner（VPSやベアメタル）では、 CIジョブの実行により、ホストのroot権限で悪意ある操作が実行され、また、その影響が持続する危険性があります。 Dockerデーモンを必要としない、代替ソフトウェアによるDockerイメージビルドを検討してください。 リポジトリ構造 .gitlab-ci.yml Dockerfile .gitlab-ci.yml # License: CC0-1.0 stages: - build build: stage: build image: docker:24.0 services: - docker:dind rules: # Release - if: $CI_COMMIT_TAG variables: DOCKER_IMAGE_NAME_AND_TAG: "${CI_REGISTRY_IMAGE}:${CI_COMMIT_TAG}" DOCKER_CACHE_FROM: "type=registry,ref=${CI_REGISTRY_IMAGE}:latest-buildcache" DOCKER_CACHE_TO: "" # Default branch - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH variables: DOCKER_IMAGE_NAME_AND_TAG: "${CI_REGISTRY_IMAGE}:latest" DOCKER_CACHE_FROM: "type=registry,ref=${CI_REGISTRY_IMAGE}:latest-buildcache" DOCKER_CACHE_TO: "type=registry,ref=${CI_REGISTRY_IMAGE}:latest-buildcache,mode=max" script: - apk add --no-cache git - docker buildx create --use - docker login -u "${CI_REGISTRY_USER}" -p "${CI_REGISTRY_PASSWORD}" "${CI_REGISTRY}" - > docker buildx build . -t "${DOCKER_IMAGE_NAME_AND_TAG}" --cache-from "${DOCKER_CACHE_FROM}" --cache-to "${DOCKER_CACHE_TO}" --push ※ docker buildx buildのコマンドは複数行になっていますが、2行目以降を1行目と異なるインデント数にしないでください。2行目以降が別のコマンド扱いになり、動作しなくなります。 docker buildx create --use docker buildx build実行時に、以下のようなエラーが出るため追加しています。 ...

https://docs.gitlab.com/ee/user/project/pages/ リポジトリのGitLab Pages機能を有効化したあと、 GitLab CI上でpagesというジョブにpublicというパスのArtifactがあるとき、 自動的にpages:deployというジョブが実行され、GitLab Pagesへのデプロイが行われる。 リポジトリがプライベートリポジトリのとき、 デプロイされたGitLab Pagesは、GitLabアカウントで認証が行われる。 .gitlab-ci.yml https://docs.gitlab.com/ee/user/project/pages/getting_started/pages_from_scratch.html#specify-a-stage-to-deploy image: ruby:2.7 workflow: rules: - if: '$CI_COMMIT_BRANCH' pages: stage: deploy script: - gem install bundler - bundle install - bundle exec jekyll build -d public artifacts: paths: - public rules: - if: '$CI_COMMIT_BRANCH == "main"'

Docker Hubにアクセストークンを追加する。 https://hub.docker.com/settings/security リポジトリのSettingsから、Secretsを開き、New repository secretから DOCKER_USERNAME、DOCKER_PASSWORDを追加する。 DOCKER_USERNAMEはDocker Hub上のユーザ名、 DOCKER_PASSWORDはアクセストークンを設定する。 以下のファイルをリポジトリに追加する（ファイル名docker.ymlは変更可）。 mainブランチにgit pushされたとき、Dockerイメージのビルドが走り、イメージがDocker Hubにdocker pushされる。 .github/workflows/docker.yml name: Push to Docker registry on: push: branches: - main jobs: push: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: Login to Docker Hub uses: actions-hub/docker/login@master env: DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }} DOCKER_PASSWORD: ${{ secrets.DOCKER_PASSWORD }} DOCKER_REGISTRY_URL: docker.io - name: Build :latest if: success() run: docker build -t username/imagename:latest . - name: Deploy :latest if: success() uses: actions-hub/docker@master with: args: push username/imagename:latest

2023-05-18 追記：この記事には、改訂版（2023年版）があります。 リポジトリ構造 .gitlab-ci.yml app/ Dockerfile .gitlab-ci.yml stages: - build build: stage: build image: docker:20.10 services: - docker:dind rules: - if: $CI_COMMIT_BRANCH == "main" script: - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY - docker build ./app -t $CI_REGISTRY_IMAGE:latest - docker push $CI_REGISTRY_IMAGE:latest

GitHub Actions実行中に生成したbuildディレクトリの内容を別ブランチにpushする。 github:s0/git-publish-subdir-action name: Build on: push: branches: - master jobs: deploy: name: Build runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: Setup Python uses: actions/setup-python@v2 with: # Version range or exact version of a Python version to use, using SemVer's version range syntax. python-version: 3.x - name: Install dependencies run: pip3 install -r requirements.txt - name: Build run: python3 app/main.py # run: | # python3 app/cmd1.py # python3 app/cmd2.py # https://github.com/s0/git-publish-subdir-action - name: Push to build branch uses: s0/git-publish-subdir-action@master env: REPO: self BRANCH: build FOLDER: build GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

概要 新しく静的サイトジェネレータでブログ環境を整備した。 細かい使い方には触れないが、構成を書いておく。 静的サイトジェネレータとCI/CD 静的サイトジェネレータ 静的サイトジェネレータというのはSphinx（Python製）とかJekyll（Ruby製、GitHub Pages標準らしい）とかHugo（Go製）みたいなやつで、 MarkdownだとかreStructuredTextだとかのファイル群からHTMLを生成するツール。 Sphinx Jekyll Hugo Miyadaiku MiyadaikuはPython製の静的サイトジェネレータ。 Flaskで使うテンプレートエンジンのJinja2が使えることが特徴みたい。Jinja2はDjangoのテンプレートエンジンに似ている。 テンプレート上でどんな変数が使えるかはMiyadaikuの領域なので、ドキュメント（とサンプルテンプレート、ソースコード）を見ていくしかないかも。 github:miyadaiku/miyadaiku pypi:miyadaiku GitHub Actions GitHub上のリポジトリに対してpushやPull Requestがなされた時に事前に指定した処理を実行することのできるGitHubの機能。 Jenkinsなどに近そう。また、GitLabにも同様の機能があったはず。 GitHubのサーバで動く仮想環境上でDockerのような使い方でテストケースの実行やリリースファイルのビルド、サーバへのデプロイ、 つまりCI（Continuos Integration、テストやビルドの自動化）/CD（Continuous Delivery、デプロイの自動化）を設定できる。 Pull Requestなどへの自動ラベル付けやSlackへの通知なんかも設定することがあるのかな。 この設定はYAMLファイルとしてGitリポジトリ内に保存しますが、秘密鍵/トークンなどの情報を参照するための機能もあるみたい。 バージョン管理システム的な点ではGitは分散型なので文書自体の分散バージョン管理はできるが、 GitHubが落ちたら解消するまで（手元にリポジトリがあっても）GitHub ActionsによるCI/CDができないのが難点な気がする。 GitHub Status 考えていること レンダリング後のHTMLファイルの分離 Markdownを書いている時に見えるところに（レンダリング後の）HTMLファイルを置きたくない。 できれば何も考えずに（Markdownで書いた）メモファイルを置くのに使っていた適当なディレクトリの上でコマンドを実行したら HTTPサーバを介して（オプションで指定したテーマなどで）いい感じにレンダリングしてくれるようなものがいい （HTMLファイル自体にファイルシステムからアクセスできる必要はない）と思っていた。 このHTMLはMarkdownファイル群とレンダリングのオプションだけでいつでも生成可能なので、 レンダリング後のファイル自体が見えなければ、後からこのファイルを何かの間違いで編集してしまって正規性（再レンダリングしても差分がない状態）が崩れてしまうことがない。 それからMarkdownファイルをGitで管理する場合、レンダリング後のファイルの差分には実質的に意味がないので、（見える）commitに含めたくない気持ちがある。 この部分は適切に.gitignoreやCI/CDを設定すれば大抵の静的サイトジェネレータで実現可能だろうと思う。 今回はGitHub Actionsを使って、GitHub上の仮想環境にリポジトリから文書を読み込んでHTMLを自動生成し、文書と履歴を共有しない別ブランチ（gh-pages）に自動でcommitされるように設定する。 GitHub Actionsを動かすには.github/workflows以下にYAMLファイルを配置する。例えばこのような感じ。GitHub Pagesへのデプロイ（gh-pagesブランチの更新）にはgithub:peaceiris/actions-gh-pagesを使っている。 # deploy.yml name: Deploy # Controls when the action will run. Triggers the workflow on push or pull request # events but only for the master branch on: push: branches: [ master ] # A workflow run is made up of one or more jobs that can run sequentially or in parallel jobs: # This workflow contains a single job called "build" build: # The type of runner that the job will run on runs-on: ubuntu-latest # Steps represent a sequence of tasks that will be executed as part of the job steps: # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it - uses: actions/checkout@v2 - name: Setup Python uses: actions/setup-python@v2 with: # Version range or exact version of a Python version to use, using SemVer's version range syntax. python-version: 3.x - name: Install dependencies run: pip3 install -r requirements.txt - name: Run miyadaiku-build run: miyadaiku-build --output public . - name: Deploy uses: peaceiris/actions-gh-pages@v3 with: github_token: ${{ secrets.GITHUB_TOKEN }} publish_dir: ./public name、runのところをコピーして増やせばコマンドを増やすことができる。 ...