Gitlab on ポンコツ地方エンジニアの技術ブログ

Cloudflare Pages で静的サイトを公開する（GitLab 連携）

Sun, 17 May 2026 00:00:00 +0900

前提・環境

ソース管理: GitLab (GitHub でもやり方は同じ)
ホスティング: Cloudflare Pages
DNS: Cloudflare（既存ドメインのサブドメインに展開する想定）

GitLab 側で必要なこと

ほぼ何もしなくて構いません。
.gitlab-ci.yml を書く必要はなく、Cloudflare Pages が直接 git clone してビルドします。

最低限の準備は次のとおりです。

リポジトリが Cloudflare からアクセスできること（Public ならそのまま、Private なら次節の OAuth で許可します）
プロダクションブランチ（main など）を決めておくこと

ブランチ運用は Cloudflare Pages 側で自動的に処理されます。

プロダクションブランチへの push → 本番デプロイ
それ以外のブランチへの push → 自動でプレビュー URL が発行される

Cloudflare Pages 側のセットアップ

Cloudflare ダッシュボード → Workers & Pages を選択します。

Create application を選択します。

下部にある Get started をクリックします。

Import an existing Git repository の Get started を選択します。

Git プロバイダの接続

GitHub だけでなく GitLab も公式サポートされています。
GitLab のタブを選択し、Connect GitLab から OAuth で認証を行います。
認証後、対象リポジトリを選び、Begin setup を選択します。

ビルド設定で指定する項目

Framework preset: 使っているフレームワークに該当があれば選びます。自前のシェルスクリプトでビルドするなら None で構いません
Build command: リポジトリ直下から実行されるビルドコマンド
Build output directory: 成果物のディレクトリ（例: dist、public）
Root directory: 通常は空欄でリポジトリ直下
Environment variables: 必要に応じて設定します

初回デプロイの確認

Save and Deploy を選択すると数分でビルドが走り、プレビュー URL（<project>.pages.dev）が発行されます。
ここでまず動作確認をしてから、カスタムドメインを当てに行きます。

カスタムドメインの設定

DNS も Cloudflare で管理しているなら、ほぼワンクリックで終わります。

初回デプロイ完了後、Add custom domain を選択するとカスタムドメインの設定画面に移行します。

メニューからアクセスする場合は、Workers & Pages の Custom domains タブを選択します。

Set up a custom domain を選択します。
続いて、適用したいドメインを入力し、Continue をクリックします。
すると、CNAME レコードが自動で追加されます（手動編集は不要です）。

Activate domain をクリックすると設定完了です。
TLS 証明書も Cloudflare 側で自動発行されます（数分待ちます）

SSL/TLS モードの変更

SSL/TLS モードは Full (strict) にしておきます。
Cloudflare Pages の出口側は有効な証明書を持つので、Full (strict) でもエラーにはならず、Flexible のように HTTPS が中途半端な状態を避けられます。

SSL/TLS の Overview を選択し、SSL/TLS encryption の Configure をクリックします。

Full (Strict) を選択して、Save をクリックして完了です。

気をつけること

`NODE_VERSION` の明示

Cloudflare Pages のデフォルト Node は古いことがあります。
package.json の engines だけでは効かないので、ビルド設定の環境変数で明示します。

ビルド時間と無料枠

無料枠は 同時ビルド 1 並列・月 500 回までです。
push のたびにビルドが走るので、頻繁な push を続けると上限に近づきます。CI ライクに何度も push しまくる運用には向きません。

初回ビルドは npm install がフレッシュで 5〜10 分かかることもあります。2 回目以降はキャッシュが効きます。

プレビュー URL の検索エンジン除外

Cloudflare Pages は本番ドメイン以外（<project>.pages.dev や <branch>.<project>.pages.dev）にも 自動で X-Robots-Tag: noindex を付けます。Google にプレビュー版がインデックスされる事故は基本的に起きません。

まとめ

すべて 無料枠で完結し、自前のサーバー運用はゼロです。
GitLab に push して数分で本番反映される、最小構成になっています。

GitLab Pages + Cloudflare プロキシでも同じことはできますが、TXT 検証や SSL モード調整など「2 サービスを連携させるための作業」が発生します。
Cloudflare 内で完結させると、覚えることが 1 箇所にまとまって精神的に楽です。

Cloudflare で取得した独自ドメインを GitLab Pages に設定する方法

Tue, 12 May 2026 00:00:00 +0900

全体の流れ

GitLab側: カスタムドメイン登録と検証コードの取得
GitLab側: Pagesの公開範囲（Visibility）の設定
Cloudflare側: DNSレコード（CNAME/TXT）の設定
最終確認: SSL証明書の発行とプロキシの有効化

1. GitLab側でカスタムドメインを追加する

まず、GitLabに「このドメインを使います」と伝えて、検証用のコードを発行します。

プロジェクトの左メニュー [Deploy] > [Pages] を開きます。
Domains & settings のタブを選択し、[Add Domain] をクリックします。
使用したいドメイン（例: blog.example.com）を入力し、[Create new domain] をクリックします。
表示された画面から以下の2点をメモします。
- TXTレコードの値: gitlab-pages-verification-code=...
- CNAMEのターゲット: username-12345.gitlab.io

自分の「名前空間（Target）」を確認する方法

GitLab PagesのデフォルトURLを確認してください。例：https://username-12345.gitlab.io/my-project

この場合、Cloudflare側で指定するターゲットは username-12345.gitlab.io です。 .gitlab.io の直前まで（スラッシュより前のホスト部分）が、あなたの「名前空間（Namespace）」となります。

2. プロジェクトはPrivateのまま、Pagesだけを公開する

「ソースコードは見せたくないが、ブログとして誰でも見れるようにしたい」場合は、以下の設定が必須です。

[Settings] > [General] を開きます。
[Visibility, project features and permissions] セクションを展開します。
Project visibility は [Private] のままにします。
下の方にある [Pages] の権限設定を [Everyone] に変更します。
- ※ここが Only Project Members だと、独自ドメインにアクセスしてもGitLabのログイン画面が出てしまいます。
[Save changes] で保存します。

3. Cloudflare側でDNSレコードを設定する

Cloudflareの管理画面の左メニューから [Domains] > [Overview] を開き、該当のドメインをクリックします。

さらに左メニューから [DNS] > [Records] を開き、Add record をクリックして、以下の2つのレコードを追加します。

① CNAMEレコード（接続用）

項目	設定値の例	補足
Type	`CNAME`
Name	`blog`	サブドメイン部分のみ入力
Target	`username-12345.gitlab.io`	先ほど確認したGitLabのホスト名
Proxy status	DNS only (灰色雲)	SSL発行をスムーズにするため最初は必ず「灰色」にする

② TXTレコード（ドメイン所有確認用）

項目	設定値の例	補足
Type	`TXT`
Name	`_gitlab-pages-verification-code.blog`	`_gitlab-pages-verification-code.` の後にサブドメイン名を付ける
Content	`gitlab-pages-verification-code=...`	GitLabからコピーした検証コード

4. 仕上げ：検証とプロキシ有効化

① GitLabで検証する

DNS設定後、GitLabのPages設定画面で [Verify]（更新マーク）ボタンを押します。「Verified」になれば成功です。

⚠️ すぐに認証されない場合があります。 Cloudflare管理ドメインはDNSのTTLが短いため反映は比較的早いですが、DNSの浸透には最大48時間かかることがあります。Verifyが通らない場合は時間をおいて再試行してください。

② SSL証明書の発行を待つ

検証完了後、数分〜30分ほどでLet’s Encryptの証明書が自動発行され、https:// でアクセスできるようになります。

③ CloudflareのプロキシをONにする

https:// で正常に表示されたことを確認してから、CloudflareのDNSレコードを [Proxied（オレンジ雲）] に切り替えます。

プロキシを ON にするメリット

CDNによる高速化: 画像やJSがキャッシュされ、表示速度が向上します。
セキュリティ強化: DDoS保護やWAFが利用可能になります。
アクセス解析: Cloudflare側でトラフィックやアクセス地域を確認できます。

④ CloudflareのSSL/TLS設定を変更する

プロキシを有効にしたら、Cloudflareの [SSL/TLS] > [Overview] を開き、暗号化モードを確認します。

モード	説明	推奨
`Full`	GitLab側の証明書を検証せず暗号化	初心者・通常利用向け
`Full (strict)`	GitLab側にLet’s Encryptなど信頼されたCA発行の証明書が必要	SSL発行が正常に完了していれば利用可

⚠️ Full (strict) はSSL証明書が有効な状態でのみ機能します。証明書の発行前や更新タイミングで一時的にエラーになるリスクがあるため、迷ったら Full を選択してください。

5. 運用上の注意：キャッシュの扱い

Cloudflareのプロキシを有効にすると、CSSや画像などの静的ファイルがキャッシュされます。 サイトを更新しても古いコンテンツが表示される場合は、Cloudflareのキャッシュをクリアしてください。

手動でキャッシュをクリアする方法:

Cloudflareダッシュボードの [Caching] > [Configuration] を開く
[Purge Cache] > [Purge Everything]（または特定URLを指定）を実行する

まとめ

GitLab Pagesを独自ドメインで運用する主なポイントは以下の3点です。

正しいCNAMEターゲットを設定する — GitLabのPages URLから実際のホスト名を確認して使う
PagesのVisibilityを「Everyone」にする — Privateプロジェクトでも公開アクセスを許可する
SSL発行前はプロキシを灰色に保つ — 証明書が発行されてからオレンジ雲に切り替える

ターミナルから GitLab を操る：公式 CLI「glab」導入・活用ガイド

Sun, 10 May 2026 00:00:00 +0900

ブラウザを開かずに Issue を確認したり、MR（マージリクエスト）を作成したり、CI/CD パイプラインの状況を監視したりできるため、エンジニアの生産性を大きく向上させてくれます。

1. インストール方法

devcontainer を使っていない場合は、ホスト側に glab をインストールして使います。devcontainer を使う場合は、コンテナイメージに glab をインストールしておくか、devcontainer の Dockerfile / devcontainer.json で導入しておきます。

一般的な手順としては、Dockerfile に curl で glab の公式パッケージを取得して apt install するか、apt リポジトリからインストールする形です。コンテナ内で glab --version を実行して、インストールが正しくできていることを確認してください。

OS ごとの主要なインストールコマンドは以下の通りです。

OS	インストールコマンド
macOS	`brew install glab`
Windows (winget)	`winget install glab`
Windows (scoop)	`scoop install glab`
Linux (Ubuntu/Debian)	`sudo apt install glab`（※公式リポジトリ推奨）

インストール後、glab --version で正常にインストールされたか確認しましょう。

バージョンが古かったり、上記でインストールできない場合は、公式リリースからダウンロードしてインストールします。

https://gitlab.com/gitlab-org/cli/-/releases

例えば以下です。

cd /tmp
wget https://gitlab.com/gitlab-org/cli/-/releases/v1.97.0/downloads/glab_1.97.0_linux_amd64.deb
sudo dpkg -i glab_1.97.0_linux_amd64.deb

2. 初期設定（認証）

インストールが完了したら、GitLab アカウントと連携させます。

glab auth login

実行すると対話形式で以下の項目を聞かれます：

GitLab インスタンスの種類: GitLab.com か自前運用のサーバー（Self-Managed）かを選択。
認証方法: Web を選択するとブラウザが開いて簡単に認証できます。
プロトコル: SSH または HTTPS を選択。

設定が完了すると、~/.config/glab-cli/config.yml に設定が保存されます。

3. devcontainer での認証情報共有

glab の認証情報は ~/.config/glab-cli/config.yml に保存されます。devcontainer をリビルドするとコンテナ内の ~/.config/glab-cli が消えて再ログインが必要になるため、ホスト側の設定を bind mount で共有しておくと便利です。

一般的には、.devcontainer/devcontainer.json の mounts にホストの ~/.config/glab-cli を追加します。例:

"mounts": [
 "source=${localEnv:HOME}/.config/glab-cli,target=/home/vscode/.config/glab-cli,type=bind,consistency=cached"
]

もし gh など別の CLI も devcontainer 内で使うなら、同じように ~/.config/gh を共有することもできます。

ホスト側に ~/.config/glab-cli が存在していれば、ホストで一度 glab auth login しておけばコンテナ側でも同じ認証を使えます。ホストにディレクトリがない場合は、mkdir -p ~/.config/glab-cli で空ディレクトリを作成しておけばマウントが通ります。

このようにしておけば、glab の認証設定をホストと devcontainer で共通化し、コンテナ再構築後も再ログイン不要で作業を続けやすくなります。

4. よく使う基本コマンド集

glab のコマンド体系は glab <リソース名> <アクション> という形式で、gh と非常に似ています。

■ Merge Request (MR) を操作する

開発のメイン作業となる MR 操作です。

MR の一覧表示: glab mr list
MR の作成: glab mr create --fill（現在のブランチから自動入力で作成）
MR の詳細表示: glab mr view <id>
MR を承認: glab mr approve <id>
MR をマージ: glab mr merge <id>

■ Issue (課題) を管理する

Issue 一覧: glab issue list
Issue 作成: glab issue create -t "タイトル" -description "内容"

■ CI/CD パイプラインを確認する

glab 独自の強力な機能の一つが、CI パイプラインのリアルタイム監視です。

パイプラインの状態表示: glab pipeline status
実行中のログをリアルタイム表示: glab pipeline ci view
失敗したジョブの再実行: glab ci retry

4. `gh` と `glab` の主な対応表

GitHub CLI に慣れている方向けのクイック比較です。

機能	GitHub (`gh`)	GitLab (`glab`)
認証	`gh auth login`	`glab auth login`
PR / MR 作成	`gh pr create`	`glab mr create`
PR / MR チェックアウト	`gh pr checkout <id>`	`glab mr checkout <id>`
リポジトリ作成	`gh repo create`	`glab project create`
CI 監視	`gh run watch`	`glab pipeline ci view`

5. 自社運用の GitLab (Self-Managed) で使うコツ

glab は GitLab.com だけでなく、会社などで独自に立てている GitLab サーバーでも使えます。その場合、環境変数でホストを指定しておくと便利です。

export GITLAB_HOST=gitlab.example.com

まとめ

glab を導入することで、「コードを書く → プッシュする → ブラウザで MR を作る → CI の完了を待つ」という一連の流れをターミナルから一歩も出ずに行えるようになります。

まずは glab mr list から始めて、快適な GitLab ライフを送りましょう！

参考リンク:

GitLab Pages でディレクトリ一覧を表示したい

Mon, 25 Dec 2023 00:00:00 +0900

GitLab Pages で公開しているサイトにアクセスしたときに、配下ディレクトリの一覧を表示させる方法です。

GitLab 12.8 までは nginx の autoindex を有効にして index of で表示させることができたようですが、セキュリティの観点からその機能は削除されたそうです。

なので、どうにかしてインデックスページを作成し、GitLab Pages に公開するしかありません。例えば、Hugo や Jekyll で Sitemap やインデックスページの自動生成機能を使う方法があるようです。

ただ、今回私はシェルスクリプトファイルで作成することにしました。

以下、サンプルです。

#!/bin/bash

# 公開ディレクトリ内のディレクトリ一覧を取得
dirs=(public/*/)

# HTMLで一覧を表示するための変数
list="<ul>"

# ディレクトリのHTMLリストを生成
for d in "${dirs[@]}"; do
 # フォルダ一覧のみに制限するため、publicディレクトリ内のサブディレクトリのみを対象としています。
 dir=$(echo $d | sed -e 's/public\///' -e 's/\///')
 list="$list<li><a href='$dir'>$dir</a></li>"
done

list="$list</ul>"

# index.htmlファイルを作成
title="タイトル"
cat > public/index.html << EOF
<!DOCTYPE html>
<html>
 <head>
 <meta charset="UTF-8">
 <title>$title</title>
 </head>
 <body>
 <h1>$title</h1>
 $list
 </body>
</html>
EOF

これを、.gitlab-ci.yml の script の最後に実行すれば OK です。

上記はディレクトリに限定していますが、応用でファイル一覧を出力できると思います。

GitLab Pages でブランチ毎にディレクトリを分けて公開したい

Wed, 20 Dec 2023 00:00:00 +0900

mkdocs で作成したサイトを GitLab Pages で公開していたのですが、これをブランチ毎にディレクトリを分けて公開するようにしました。

基本的には、キャッシュを有効にするだけで可能です。
各ブランチでの成果物も一緒に Pages で公開したいため、キャッシュのキーは固定値にします。
以下、 .gitlab-ci.yml の抜粋です。

pages:
 stage: build
 script:
 - mkdocs build
 - rm -rf public/${CI_COMMIT_REF_NAME}
 - mv site public/${CI_COMMIT_REF_NAME}
 artifacts:
 paths:
 - public
 cache:
 # ブランチ毎に別のキャッシュを利用したい場合はブランチ名をキーにするが、
 # 今回は全ブランチのビルド結果も一緒に公開したいため、キーは全ブランチで共通の固定値にする
 key: "common-key"
 #key: "$CI_COMMIT_REF_NAME"
 paths:
 - public

site ディレクトリが mkdocs の成果物が入っているディレクトリですが、これを public/ブランチ名 に配置しています。

注意点

デフォルトでは、保護されたブランチと保護されていないブランチではキャッシュが共有されないため、この場合はプロジェクトの設定変更が必要です。
これを知らずに何度試してもキャッシュが共有されずはまっていました・・・。

https://gitlab-docs.creationline.com/ee/ci/caching/#use-the-same-cache-for-all-branches

変更する設定は以下です。

サイドメニューより、Settings > CI/CD を選択
General pipelines を開く
Use separate caches for protected branches のチェックボックスをオフにする
Save changes をクリックして保存

参考 URL

GitLab CI/CD で Uploading artifacts to coordinator... too large archive のエラーが表示された

Fri, 08 Jul 2022 00:00:00 +0900

GitLab CI/CD で成果物をアップロードする際に、サイズが大きすぎるとのエラーが表示されました。

ERROR: Uploading artifacts to coordinator... too large archive id=XXXX responseStatus=413 Request Entity Too Large status=413 Request Entity Too Large token=XXXXX
FATAL: too large 
ERROR: Job failed: exit status 1

GitLab の設定

まずは GitLab の以下の設定を確認します。

「Settings > Continuous Integration and Deployment > Maximum artifacts size (MB) 」

デフォルトでは 100MB に設定されているので、必要ならここを変更します。

しかし、今回は 7MB 程度のファイルだったので、これが原因ではありませんでした。

リバースプロキシの設定

今回 nginx でリバースプロキシの設定を行っていたのですが、client_max_body_size の設定を行っていなかったのが原因でした。
client_max_body_size のデフォルト値は 1MB だそうです。
とりあえず以下のように 0 を設定して無制限にしておきました。

server {
 listen 80;
 server_name example.com;
 client_max_body_size 0;
}

参考 URL

https://pauledenburg.com/gitlab-ci-upload-artifact-fails-large/

OpenAPI + Swagger + Redoc + GitLab Pages で API ドキュメントを管理する

Tue, 24 May 2022 00:00:00 +0900

APIドキュメントを簡単に作成・閲覧できるようにしたいと思い、OpenAPI で作成、Swagger および Redoc で表示、GitLab Pages で公開までを行いました。

概要

OpenAPI で yaml を作成
GitLab CI/CD により自動で Swagger および Redoc でビルドし、GitLab Pages に公開
ローカル環境用に Swagger および Redoc を Docker で動かす

ディレクトリ構造

今回試しに作成したファイル一式は以下となります。詳細は後述します。

$ tree -a
.
├── .gitlab-ci.yml
├── README.md
├── docker-compose.yml
├── openapi
│ └── openapi.yaml
└── public
 └── index.html

OpenAPI の yaml を作成

Open API Specification (OAS) は REST API の仕様を記述するフォーマットです。記述方法についてはググったらたくさん出てくるので割愛します。

例えば、以下のような yaml を作成します。

openapi: 3.0.0
info:
 version: 1.0.0
 title: OpenAPI Sample
paths:
 /users:
 get:
 summary: Get Users
 responses:
 '200':
 description: OK

ローカル環境の作成

ひとまず GitLab は置いておき、まずはローカル環境で Swagger および Redoc が動くようにしてみます。
３つのサービスを動かしたかったので、docker-compose 使いました。
作成した docker-compose.yml は以下です。

version: '3'
services:
 # エディター
 swagger-editor:
 image: swaggerapi/swagger-editor
 ports:
 - "8081:8080"
 # ビューワー（Swagger-UI 版）
 swagger-ui:
 image: swaggerapi/swagger-ui
 volumes:
 - ./openapi:/usr/share/nginx/html/openapi
 environment:
 API_URL: ./openapi/openapi.yaml # Swagger UIの画面を開いたときに初期値として表示するファイル
 ports:
 - '8082:8080'
 # ビューワー（Redoc 版）
 redoc:
 image: redocly/redoc
 volumes:
 - ./openapi:/usr/share/nginx/html/openapi
 environment:
 SPEC_URL: ./openapi/openapi.yaml # Redocの画面を開いたときに初期値として表示するファイル
 PORT: 8080 # nginx port(default:80)
 ports:
 - '8083:8080'

特に難しいところはないかと思います。
docker-compose up で動かしたあと、ブラウザでアクセスすればOKです。

http://localhost:8081 で Swagger Editor にアクセスして編集が行えます。
http://localhost:8082 で Swagger UI での表示を確認できます。
http://localhost:8083 で Redoc での表示を確認できます。

ただ、Swagger Editor は別にいらなかったかもしれません。
私の場合、結局 VSCode で yaml を編集し、ブラウザの表示を更新して確認、ってやってます。

閲覧に関しては Swagger より Redoc のほうが個人的に見やすいですね。

GitLab Pages で公開する

ローカルでの環境は以上で整ったので、次は GitLab に push したら自動ビルドを行って GitLab Pages に公開するように設定します。
GitLab Pages や GitLab CI/CD については割愛します。

Swagger + GitLab Pages については以下のページが参考になりました。

https://lab.astamuse.co.jp/entry/2019/11/13/114500

ただ、今回 swagger-ui-dist のバージョンを上げたので、sed コマンドで修正するファイルを index.html から swagger-initializer.js に変更する必要がありました。
これについては以下のページが参考になりました。

https://qiita.com/hidao/items/d13e7dda3da02d37dd45

Redoc + GitLab Pages については以下のページが参考になりました。

https://medium.com/hoursofoperation/auto-generate-swagger-docs-to-gitlab-pages-ca040230df3a

以上の２つを組み合わせ、最終的に作成した .gitlab-ci.yml は以下です。
Swagger と Redoc のそれぞれで閲覧できるようにディレクトリを分けてみました。
プロキシ環境下でなければプロキシ関係の設定は不要です。

image: node:18-alpine

variables:
 # プロキシサーバー
 PROXY: 'http://example:8080'
 # ドキュメントのあるディレクトリ
 DOCS_FOLDER: "swagger"
 # ドキュメントファイル
 SPEC_TO_DISPLAY: "openapi.yaml"
 # デプロイ先
 DEPLOY_SWAGGER: "public/swagger"
 DEPLOY_REDOC: "public/redoc"

cache:
 paths:
 - ./node_modules

pages:
 stage: deploy
 before_script:
 # プロキシ環境下での下準備
 - npm -g config set proxy $PROXY
 - npm -g config set https-proxy $PROXY
 - npm -g config set registry http://registry.npmjs.org/
 - npm config set strict-ssl false
 # Swagger UI
 - npm install swagger-ui-dist@4.11.1
 # Redoc
 - npm install -g redoc-cli@0.13.14
 script:
 - mkdir -p $DEPLOY_SWAGGER
 - mkdir -p $DEPLOY_REDOC
 # Swagger UI
 - cp -rp node_modules/swagger-ui-dist/* $DEPLOY_SWAGGER
 - cp -rp $DOCS_FOLDER/* $DEPLOY_SWAGGER
 - sed -i "s#https://petstore\.swagger\.io/v2/swagger\.json#$SPEC_TO_DISPLAY#g" $DEPLOY_SWAGGER/swagger-initializer.js
 # Redoc
 - redoc-cli build -o $DEPLOY_REDOC/index.html $DOCS_FOLDER/$SPEC_TO_DISPLAY
 artifacts:
 paths:
 - public
 only:
 - main

ちなみに、Swagger の yaml ファイルは GitLab 上で Swagger でプレビュー表示されるので、外部に公開する必要がなければこれで十分かもしれません。

https://blog.kyanny.me/entry/2020/08/06/012807

参考 URL

MkDocs + GitLab Pages でドキュメント管理

Mon, 23 May 2022 00:00:00 +0900

マークダウンで書いたドキュメントを簡単に管理・閲覧できるようにしたいと思い、MkDocs と GitLab Pages を使ってみました。

概要

Markdown で書いたドキュメントを MkDocs を使って静的サイトに変換します。
MkDocs のビルドは GitLab CI/CD を使って自動で行い、出力された静的サイトを GitLab Pages で公開します。
また、ローカル環境での確認用に、Docker を使って MkDocs が動作する環境を作成します。

GitLab-Runner の設定は済んでいる前提です。

ローカル環境の構築

ひとまず GitLab は置いておき、まずはローカル環境で MkDocs が動くようにしてみます。
作成した Dockerfile は以下です。

FROM python:3.9-slim

RUN pip install \
 mkdocs \
 mkdocs-material \
 pygments

CMD ["mkdocs", "serve", "-a", "0.0.0.0:8000"]

ビルドします。

$ docker build -t mkdocs .

ドキュメントの新規作成（初回のみ）

ドキュメントを何も作成していない状態でコンテナを起動するとエラーとなります。
まずはコンテナ起動時に mkdocs new doc を実行してドキュメントを新規作成しました。

docker run -it --rm \
 -u "$(id -u $USER):$(id -g $USER)" \
 -v $(pwd)/workspace:/workspace \
 --workdir="/workspace" \
 mkdocs mkdocs new doc

以下のようにファイルが作成されます。

$ tree workspace/
workspace/
└── doc
 ├── docs
 │   └── index.md
 └── mkdocs.yml

コンテナの起動

ドキュメント作成済みであれば、以下のようにしてコンテナを起動します。

docker run -it --rm \
 -u "$(id -u $USER):$(id -g $USER)" \
 -v $(pwd)/workspace:/workspace \
 -p 8000:8000 \
 --workdir="/workspace/doc" \
 mkdocs

ブラウザで http://localhost:8000 にアクセスすれば MkDocs のページが表示されます。

GitLab Pages で公開する

ローカルでの環境は以上で整ったので、次は GitLab に push したら MkDocs のビルドを行って GitLab Pages に公開するように設定します。
作成した .gitlab-ci.yml は以下です。

image: python:3.9-slim

before_script:
 - pip install --upgrade pip
 - pip install mkdocs
 - pip install mkdocs-material
 - pip install pygments

pages:
 stage: build
 script:
 - cd workspace/doc
 - mkdocs build
 - mv site ../../public
 artifacts:
 paths:
 - public
 only:
 - main

特に難しいところはないかと思います。
mkdocs build でビルドすると site に出力されるので、public にリネームして GitLab Pages に公開しています。

参考 URL

GitLab でプライベートリポジトリの分も草を生やす

Mon, 02 May 2022 00:00:00 +0900

GitLab のプロフィールに表示されるコミットグラフですが、デフォルトでは自分以外の人からは Public なリポジトリの分しか見えません。

Private なリポジトリのコミット分も見えるようにするには、以下の設定を変更します。

Preferences > Profile > Private contributions

参考 URL

https://www.igorkromin.net/index.php/2018/09/13/gitlab-finally-shows-private-project-contributions-in-the-profile-commit-graph/

Ubuntu に GitLab-Runner を直接インストールする

Thu, 14 Apr 2022 00:00:00 +0900

docker で GitLab-Runner を動かしたことはありましたが、今回初めてホストに直接インストールしました。

公式ドキュメントは以下です。

https://docs.gitlab.com/runner/install/

インストール

apt でインストール

まずはリポジトリを追加します。

$ curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash

apt でインストールします。

$ sudo apt-get install gitlab-runner

しかし、この方法でインストールしたら結構古いバージョン (11.2.0) がインストールされてしまいました。
最新のバージョンは 14.9.1 のはずなんですが・・・。

今動かしている GitLab と互換性がなく上手く動かなったので、最終的には次に示すように deb パッケージからインストールしました。

deb パッケージからインストール

https://docs.gitlab.com/runner/install/linux-manually.html

ドキュメントだと curl を使うようになっていますが、上手くダウンロードできなかったのと、環境変数 arch が空だったので、以下のコマンドでダウンロードしました。

$ wget "https://gitlab-runner-downloads.s3.amazonaws.com/latest/deb/gitlab-runner_amd64.deb"

次のコマンドでインストールします。

$ dpkg -i gitlab-runner_amd64.deb

GitLab への登録

インストールが完了したら Gitlab-Runner を GitLab に登録します。

https://docs.gitlab.com/runner/register/index.html#linux

$ sudo gitlab-runner register

対話形式で入力していきます。

まず、GitLab の URL を指定します。

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://gitlab.example

次にトークンを入力します。
トークンは GitLab に管理者でログインし、Menu > Admin > Runner で確認できます。

Please enter the gitlab-ci token for this runner:
U6YYzWyiQYzzfCdDH1dv

ランナーの詳細を入力します。

Please enter the gitlab-ci description for this runner:

ランナーを識別するためのタグを指定します。

Please enter the gitlab-ci tags for this runner (comma separated):

次はオプションなので何も入力せず進みました。

Enter optional maintenance note for the runner:

最後にスクリプトの実行方法を指定します。
今回はホスト上で直接実行させたかったので、shell を指定します。

Please enter the executor: virtualbox, docker+machine, docker, docker-ssh, parallels, kubernetes, shell, ssh, docker-ssh+machine:

GitLab の Menu > Admin > Runner で登録されたことが確認できます。

参考 URL

git で clone する場合に 503 エラーが表示される

Tue, 12 Apr 2022 00:00:00 +0900

ローカルネットワークにある GitLab からクローンをしようとした際、503 エラーが表示されました。

ググってみるとプロキシ設定が原因という記事が出てきますが、一応プロキシ設定はしているつもりでした。

しかし、どうやら Git はワイルドカードを使ったプロキシ設定を認識してくれないようです。

今回、環境変数 no_proxy に 192.168.1.* のように設定していたのですが、これを 192.168.1.2 のように指定すると正しく表示されました。

GitLab の root の初期パスワードを調べる

Thu, 07 Apr 2022 00:00:00 +0900

久しぶりに新規に GitLab を構築したら仕様が変わっていて困ったのでメモ。

以前は初回アクセス時にパスワード変更の画面が表示されていたと思うのですが、GitLab 14.9 では表示されませんでした。

環境

Docker で GitLab を動かしています。

gitlab-ce:14.9.2-ce

root の初期パスワードの確認

root でログインするための初期パスワードは /etc/gitlab/initial_root_password に記載されているそうです。

今回 Docker で GitLab を動かしているので、以下のようにコンテナに入ってから確認します。

$ docker exec -it gitlab bash
# cat /etc/gitlab/initial_root_password

gitlab はコンテナ名です。

root の初期パスワードの変更

初期パスワードは24時間経ったら削除されるとあるので、ログインできたらパスワードを変更しておきます。

右上のユーザーメニューから「Edit Profile」を選択
サイドメニューより「Password」を選択

参考 URL

https://qiita.com/masa2223/items/78aaf76329637e6ca12d

GitLab でリストア後に 500 エラーが表示される

Fri, 19 Nov 2021 00:00:00 +0900

GitLab でリストア自体は成功するのですが、特定のページにアクセスすると 500 エラーが表示されました。

原因は以下と同じでした。

https://kuttsun.blogspot.com/2020/01/gitlab-admin-runners-500.html

上記と同じ方法で解決もしました。

Gitlab on ポンコツ地方エンジニアの技術ブログ

Cloudflare Pages で静的サイトを公開する（GitLab 連携）

前提・環境

GitLab 側で必要なこと

Cloudflare Pages 側のセットアップ

Git プロバイダの接続

ビルド設定で指定する項目

初回デプロイの確認

カスタムドメインの設定

SSL/TLS モードの変更

気をつけること

NODE_VERSION の明示

ビルド時間と無料枠

プレビュー URL の検索エンジン除外

まとめ

Cloudflare で取得した独自ドメインを GitLab Pages に設定する方法

全体の流れ

1. GitLab側でカスタムドメインを追加する

自分の「名前空間（Target）」を確認する方法

2. プロジェクトはPrivateのまま、Pagesだけを公開する

3. Cloudflare側でDNSレコードを設定する

① CNAMEレコード（接続用）

② TXTレコード（ドメイン所有確認用）

4. 仕上げ：検証とプロキシ有効化

① GitLabで検証する

② SSL証明書の発行を待つ

③ CloudflareのプロキシをONにする

プロキシを ON にするメリット

④ CloudflareのSSL/TLS設定を変更する

5. 運用上の注意：キャッシュの扱い

まとめ

ターミナルから GitLab を操る：公式 CLI「glab」導入・活用ガイド

1. インストール方法

2. 初期設定（認証）

3. devcontainer での認証情報共有

4. よく使う基本コマンド集

■ Merge Request (MR) を操作する

■ Issue (課題) を管理する

■ CI/CD パイプラインを確認する

4. gh と glab の主な対応表

5. 自社運用の GitLab (Self-Managed) で使うコツ

まとめ

GitLab Pages でディレクトリ一覧を表示したい

GitLab Pages でブランチ毎にディレクトリを分けて公開したい

注意点

参考 URL

GitLab CI/CD で Uploading artifacts to coordinator... too large archive のエラーが表示された

GitLab の設定

リバースプロキシの設定

参考 URL

OpenAPI + Swagger + Redoc + GitLab Pages で API ドキュメントを管理する

概要

ディレクトリ構造

OpenAPI の yaml を作成

ローカル環境の作成

GitLab Pages で公開する

参考 URL

MkDocs + GitLab Pages でドキュメント管理

概要

ローカル環境の構築

ドキュメントの新規作成（初回のみ）

コンテナの起動

GitLab Pages で公開する

参考 URL

GitLab でプライベートリポジトリの分も草を生やす

参考 URL

Ubuntu に GitLab-Runner を直接インストールする

インストール

apt でインストール

deb パッケージからインストール

GitLab への登録

参考 URL

git で clone する場合に 503 エラーが表示される

GitLab の root の初期パスワードを調べる

環境

root の初期パスワードの確認

root の初期パスワードの変更

参考 URL

GitLab でリストア後に 500 エラーが表示される

参考 URL

`NODE_VERSION` の明示

4. `gh` と `glab` の主な対応表