CI on えやみぐさ

GitLab CI, DockerイメージをビルドしてContainer Registryにpushする（2023年版）

Thu, 18 May 2023 11:00:00 +0900

前回の記事（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実行時に、以下のようなエラーが出るため追加しています。

GitLab CI, GitLab PagesにビルドしたHTMLを公開する

Sat, 06 Nov 2021 17:00:00 +0900

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"'

GitHub Actions, DockerイメージをビルドしてDocker Hubにpushする（アクセストークン）

Sat, 10 Jul 2021 10:10:00 +0900

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

GitLab CI, DockerイメージをビルドしてContainer Registryにpushする

Sat, 29 May 2021 02:00:00 +0900

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, ビルド結果を別ブランチにpushする

Sun, 27 Sep 2020 16:30:00 +0900

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 }}

静的サイトジェネレータMiyadaiku + GitHub Actions + GitHub Pagesでブログを作る

Wed, 09 Sep 2020 09:48:39 +0900

概要

新しく静的サイトジェネレータでブログ環境を整備した。細かい使い方には触れないが、構成を書いておく。

静的サイトジェネレータとCI/CD

静的サイトジェネレータ

静的サイトジェネレータというのはSphinx（Python製）とかJekyll（Ruby製、GitHub Pages標準らしい）とかHugo（Go製）みたいなやつで、 MarkdownだとかreStructuredTextだとかのファイル群からHTMLを生成するツール。

Miyadaiku

MiyadaikuはPython製の静的サイトジェネレータ。 Flaskで使うテンプレートエンジンのJinja2が使えることが特徴みたい。Jinja2はDjangoのテンプレートエンジンに似ている。テンプレート上でどんな変数が使えるかは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のところをコピーして増やせばコマンドを増やすことができる。