オンプレGitLabでgit+CI+npmサーバー2024 の履歴(No.6)

目次†

全体としての注意†

上記のようにして動かすと、etc/ フォルダに etc/gitlab.rb というのができて、 これを書き換えれば設定を変えられる。

設定項目についてはこちらに説明がある。
https://gitlab-docs.creationline.com/omnibus/settings/configuration.html

また、ファイルの冒頭には以下の注意書きがある。

## GitLab configuration settings
##! This file is generated during initial installation and **is not** modified
##! during upgrades.
##! Check out the latest version of this file to know about the different
##! settings that can be configured, when they were introduced and why:
##! https://gitlab.com/gitlab-org/omnibus-gitlab/blame/master/files/gitlab-config-template/gitlab.rb.template
 
##! Locally, the complete template corresponding to the installed version can be found at:
##! /opt/gitlab/etc/gitlab.rb.template
 
##! You can run `gitlab-ctl diff-config` to compare the contents of the current gitlab.rb with
##! the gitlab.rb.template from the currently running version.
 
##! You can run `gitlab-ctl show-config` to display the configuration that will be generated by
##! running `gitlab-ctl reconfigure`
 
##! In general, the values specified here should reflect what the default value of the attribute will be.
##! There are instances where this behavior is not possible or desired. For example, when providing passwords,
##! or connecting to third party services.
##! In those instances, we endeavour to provide an example configuration.
 
## GitLab URL
##! URL on which GitLab will be reachable.
##! For more details on configuring external_url see:
##! https://docs.gitlab.com/omnibus/settings/configuration.html#configuring-the-external-url-for-gitlab
##!
##! Note: During installation/upgrades, the value of the environment variable
##! EXTERNAL_URL will be used to populate/replace this value.
##! On AWS EC2 instances, we also attempt to fetch the public hostname/IP
##! address from AWS. For more details, see:
##! https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html
# external_url 'GENERATED_EXTERNAL_URL'
 
## Roles for multi-instance GitLab
##! The default is to have no roles enabled, which results in GitLab running as an all-in-one instance.
##! Options:
##!   redis_sentinel_role redis_master_role redis_replica_role geo_primary_role geo_secondary_role
##!   postgres_role consul_role application_role monitoring_role
##! For more details on each role, see:
##! https://docs.gitlab.com/omnibus/roles/index.html#roles
##!
# roles ['redis_sentinel_role', 'redis_master_role']
 
## Legend
##! The following notations at the beginning of each line may be used to
##! differentiate between components of this file and to easily select them using
##! a regex.
##! ## Titles, subtitles etc
##! ##! More information - Description, Docs, Links, Issues etc.
##! Configuration settings have a single # followed by a single space at the
##! beginning; Remove them to enable the setting.
 
##! **Configuration settings below are optional.**

一方、例えば data/nginx/conf/gitlab-http.conf に nginx 関連の設定ファイルが見つかるのだけれど、 こちらの設定ファイルはサーバーを立ち上げ直すと gitlab.rb の内容を元に自動的に生成されるものなので、 手で書きかえてはいけない。

ちゃんと冒頭に

# This file is managed by gitlab-ctl. Manual changes will be
# erased! To change the contents below, edit /etc/gitlab/gitlab.rb
# and run `sudo gitlab-ctl reconfigure`.

などと書かれている。

etc/gitlab.rb を書き換えてしまうと設定情報が docker-compose.yml と gitlab.rb とに分かれてしまうので、どちらか一方にまとめた方がいいのかもしれない。

単純な見やすさからすると docker-compose.yml に書く方が良さそうなのだけれど、 gitlab-ctl diff-config を使うなら gitlab.rb でもいいのかもしれない。

docker コンテナの外から確認するなら：

LANG:console
$ docker compose exec web gitlab-ctl diff-config

ポートの指定†

外からの接続を受ける apache2 と同じマシンに置くのであれば docker-compose.yml の

     ports:
       - '8980:80'

のところは

     ports:
       - '127.0.0.1:8980:80'

として、外からの接続が直接 docker へ行かないようにする。

docker でポートを開けると ufw などのファイアウォールで許可してなくても 外向きにポートが開いてしまうので十分注意する。

https を名乗りつつ http で待ち受ける†

gitlab の設定で

      GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://myserver.com/gitlab'
        nginx['listen_port'] = 80
        nginx['listen_https'] = false

としている理由は以下の通り。

この docker イメージは external_url の設定を見て、内部の nginx で 80 番で http を待つか、443 番で https を待つかを決めている。

「どちらか片方しか有効にならない」というのが重要な点。

今実現したい構成では、外部から見た gitlab サーバーのアドレスは https://myserver.com/gitlab で https 接続になるのだけれど、その暗号化通信は間に入る apache2 が受け持つので docker 内の nginx への接続は http になる。

external_url を https としてしまうと gitlab docker は nginx を 443 番で https を待つように設定してしまい 80 番の http では繋がらなくなってしまう。

そこで 80 番で http を待つように設定しているのがこの部分だ。

サーバーに繋ぎに行って「接続をリセットされました」みたいになるときは、

LANG:console
$ sudo less data/nginx/conf/gitlab-http.conf

として gitlab 関連の nginx の設定を確かめるといい。

(これに気付くのにかなり時間がかかりました・・・)

GITLAB_OMNIBUS_CONFIG で指定可能なその他の設定†

GITLAB_OMNIBUS_CONFIG では

LANG:console
$ sudo less etc/gitlab.rb 

として表示される設定項目に値を指定できるので、 「こんなことできないのかな」と思ったときにはじっくり読むといい。

普段使いのユーザーを作っておく†

この root ユーザーを使って普段使いのユーザー（以下では "myname" とする）を作っておく。

自分で変更した root のパスワードを忘れてしまった場合†

root のパスワードを自分で変更して、その後忘れてしまうと困ったことになる。

そんな時は、

https://blog.k-bushi.com/post/tech/environment/construct-gitlab-runner-docker/#gitlab%E3%81%B8%E3%81%AE%E3%83%AD%E3%82%B0%E3%82%A4%E3%83%B3

にあるように、

LANG:console
$ docker compose exec web gitlab-rake "gitlab:password:reset"
Enter username: root
Enter password: 
Confirm password: 
Password successfully updated for user with username root.

とすればパスワードを設定しなおせるらしい。

GitLab 画面で新しい Runner インスタンスを作成†

https://myserver.com/gitlab/admin/runners

から右上の [New Instance Runner] を押す。

ここでは特別な設定をしないごく一般的な shell の動くサーバーを建てるので、

x Run untagged jobs のチェックを付けて [Create runner] とする。

docker で動かした Runner と対応付ける†

次の画面の Step 1 となっているところで

$ gitlab-runner register
   --url https://myserver.com/gitlab
   --token glrt-iqghvxb-GLHJG9WsFPT6

のようなところをコピーする。

ちょっと手直しをして次の形にして Runnner を起動した docker-compose.yml のあるフォルダで実行。

$ docker compose exec runner \
   gitlab-runner register \
       --url https://myserver.com/gitlab \
       --token glrt-iqghvxb-GLHJG9WsFPT6

コマンドを起動するといくつか質問に答えることになる。

• GitLab instance URL には指定した https://myserver.com/gitlab が入っているのでそのまま ENTER
• Enter a name for the runner にはこの Runner を識別する名前を付ける
• Enter an executor には shell を指定

これで Runner 一覧に正しく追加される。

ERROR: Verifying runner... failed → extra_hosts の設定が必要？†

何らかの事情で Runner の docker 内部から myserver.com で apache2 の動くサーバーへ到達できない場合には（LAN 内で ローカル IP を持っている場合など）、

$ docker compose exec runner \
   gitlab-runner register \
       --url https://myserver.com/gitlab \
       --token glrt-iqghvxb-GLHJG9WsFPT6
                                                   
Enter the GitLab instance URL (for example, https://gitlab.com/):
[https://myserver.com/gitlab]: <ENTER>

ERROR: Verifying runner... failed                   runner=yFiGd5DTA status=couldn't execute POST against https://myserver.com/gitlab/api/v4/runners/verify: Post "https://myserver.com/gitlab/api/v4/runners/verify": dial tcp xx.xx.xx.xx:443: connect: connection refused
PANIC: Failed to verify the runner.            

のように connection refused というエラーが出て失敗する。

このときは docker-compose.yml 内で runner に

    extra_hosts:
      - myserver.com:192.168.0.2

のようなのを追加して https://myserver.com/gitlab でサーバーへ到達できるようにしておく必要がある。

CI スクリプトの書き方†

概要：
https://gitlab-docs.creationline.com/ee/ci/yaml/gitlab_ci_yaml.html

リファレンス：
https://gitlab-docs.creationline.com/ee/ci/yaml/index.html

用語の整理：

• パイプラインは複数のステージから構成される
• 個々のステージは並列実行可能な複数のジョブから構成される
• 個々のステージは前のステージのジョブがすべて成功してから次へ進む

node 環境を準備＆ビルド＆テスト†

例えば、以下の .gitlab_ci.yml と package.json をコミットしてみる。

.gitlab_ci.yml

variables:
 NODE_VERSION: 22
 NVM_VERSION: v0.40.0

stages:
  - build
  - test
  - package

cache:
  paths:
    - dist/*

# common setting for each job
default:
  before_script:
    - ls -d "$HOME/.nvm" || (curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/${NVM_VERSION}/install.sh | bash)
    - export NVM_DIR="$HOME/.nvm"
    - \[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
    - nvm --version
    - nvm use ${NODE_VERSION} || nvm install ${NODE_VERSION}

# each job is associated to a stage
build:
  stage: build
  script:
    - echo $CI_PIPELINE_SOURCE
    - echo $CI_COMMIT_REF_NAME
    - echo $CI_COMMIT_TAG
    - echo $CI_COMMIT_BRANCH
    - npm run lint
    - npm run build
  environment: production

test:
  stage: test
  script:
    - npm run test:unit --run
 
package:
  stage: package
  only:
    - tags
  except:
    - branches
  script:
    - ls dist
  artifacts:
    name: mypackage-${CI_COMMIT_TAG}.tar.gz
    paths:
      - dist/*

package.json

LANG:console
{
        "name": "mypackage",
        "version": "0.0.1",
        "scripts": {
                "lint": "echo 'lint - success!'",
                "build": "mkdir -p dist && (echo 'Hello!' > dist/hello.txt) && echo 'build - success!'",
                "test:unit": "echo 'test:unit - success!'"
        }
}

すると build と test に成功して、

build の結果：

LANG:console
Running with gitlab-runner 17.3.1 (66269445)
  on bee01 t2X9wkLjw, system ID: r_FoHQflE05Zou
Preparing the "shell" executor 00:00
Using Shell (bash) executor...
Preparing environment 00:00
Running on 8163caea6de5...
Getting source from Git repository 00:00
Fetching changes with git depth set to 20...
Reinitialized existing Git repository in /home/gitlab-runner/builds/t2X9wkLjw/0/gitlab/osamu/gitlab-ci-hello/.git/
Checking out 504e92af as detached HEAD (ref is master)...
Skipping Git submodules setup
Executing "step_script" stage of the job script 00:07
$ ls -d "$HOME/.nvm" || (curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/${NVM_VERSION}/install.sh | bash)
ls: cannot access '/home/gitlab-runner/.nvm': No such file or directory
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 16555  100 16555    0     0  59336      0 --:--:-- --:--:-- --:--:-- 59336
=> Downloading nvm from git to '/home/gitlab-runner/.nvm'
=> Cloning into '/home/gitlab-runner/.nvm'...
* (HEAD detached at FETCH_HEAD)
  master
=> Compressing and cleaning up git repository
=> Profile not found. Tried ~/.bashrc, ~/.bash_profile, ~/.zprofile, ~/.zshrc, and ~/.profile.
=> Create one of them and run this script again
   OR
=> Append the following lines to the correct file yourself:
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
=> Installing Node.js version 22
Downloading and installing node v22.8.0...
Downloading https://nodejs.org/dist/v22.8.0/node-v22.8.0-linux-x64.tar.gz...
######################################################################## 100.0%
Computing checksum with sha256sum
Checksums matched!
Now using node v22.8.0 (npm v10.8.2)
Creating default alias: default -> 22 (-> v22.8.0 *)
=> Node.js version 22 has been successfully installed
=> Close and reopen your terminal to start using nvm or run the following to use it now:
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
$ export NVM_DIR="$HOME/.nvm"
$ \[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
$ nvm --version
0.40.0
$ nvm use ${NODE_VERSION} || nvm install ${NODE_VERSION}
Now using node v22.8.0 (npm v10.8.2)
$ npm run lint
> mypackage@0.0.1 lint
> echo 'lint - success!'
lint - success!
$ npm run build
> mypackage@0.0.1 build
> mkdir -p dist && (echo 'Hello!' > dist/hello.txt) && echo 'build - success!'
build - success!
Cleaning up project directory and file based variables 00:00
Job succeeded

test の結果:

LANG:console
Running with gitlab-runner 17.3.1 (66269445)
  on bee01 t2X9wkLjw, system ID: r_FoHQflE05Zou
Preparing the "shell" executor 00:00
Using Shell (bash) executor...
Preparing environment 00:00
Running on 8163caea6de5...
Getting source from Git repository 00:01
Fetching changes with git depth set to 20...
Reinitialized existing Git repository in /home/gitlab-runner/builds/t2X9wkLjw/0/gitlab/osamu/gitlab-ci-hello/.git/
Checking out ae25c69e as detached HEAD (ref is master)...
Removing dist/
Skipping Git submodules setup
Executing "step_script" stage of the job script 00:00
$ ls -d "$HOME/.nvm" || (curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/${NVM_VERSION}/install.sh | bash)
/home/gitlab-runner/.nvm
$ export NVM_DIR="$HOME/.nvm"
$ \[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
$ nvm --version
0.40.0
$ nvm use ${NODE_VERSION} || nvm install ${NODE_VERSION}
Now using node v22.8.0 (npm v10.8.2)
$ npm run test:unit --run
> mypackage@0.0.1 test:unit
> echo 'test:unit - success!'
test:unit - success!
Cleaning up project directory and file based variables 00:00
Job succeeded

となる。

ちゃんと初回に node がインストールされて、２回目はそれが再利用されている。

ちゃんと test をするときは report を作成するといいらしい
https://docs.gitlab.com/17.3/ee/ci/testing/unit_test_reports.html

パッケージング†

まず、上で

cache:
  paths:
    - dist/*

をしておかないと build で作成したファイルが package に引き継がれないので注意が必要だ。

そして package ステージには

  only:
    - tags
  except:
    - branches

がついているので、tag を付けたときで、なおかつそのタグがデフォルトブランチ（ここでは master）についてないとスクリプトは実行されない。

• https://stackoverflow.com/questions/42796018/how-to-run-a-gitlab-ci-yml-job-only-on-a-tagged-branch
• https://stackoverflow.com/questions/69199614/ci-commit-tag-in-if-statemets-of-regular-job

あたりを参照。

試してみよう

GitLab 画面のプロジェクトページの左上 "+" のドロップダウンから New Tag を選んで、

https://myserver.com/gitlab/myname/mypackage/-/tags/new

から 0.0.1 というタグを作成する。

・・・ん？ 新しいパイプラインが生成されないような？？？

https://forum.gitlab.com/t/pipeline-not-executed-after-commit/87173/6

によると GitLab と Runner のバージョンを合わせた方がいいと書かれてる？

GitLab のバージョンは、

$ docker compose exec web gitlab-rake gitlab:env:info

とするか、GitLab 画面左下の Help ボタンを押すことで確認できる。

ここでは 17.3.1 だった。

Runner のバージョンは GitLab の admin メニューから CI/CD - Runners で

https://myserver.com/gitlab/admin/runners

ここから個々の Runner をクリックして show detail すると、、、17.3.1 なので問題なし。

ああ、違った。

ちゃんと動いているけれど、トップ画面の緑色のチェックマークはあくまでコミットに対する CI/CD の結果で、タグに対する CI/CD の結果は Tags のページでタグの横に現れるのか。

個別のタグのページに CI/CD の結果を表示してくれないので混乱した。

https://myserver.com/gitlab/myname/gitlab-ci-hello/-/tags/0.0.1

パイプラインがすべて正しく実行されると、

https://myserver.com/gitlab/myname/gitlab-ci-hello/-/tags

のタグの横に緑のチェックが出て、その右のダウンロードメニューに artifact - package が現れる。

選択すると mypackage-0.0.1.tar.gz を落とせた。

メニュー自体の表示を mypackage-0.0.1.tar.gz にすることはできないのかな？？？

TODO: リリース時にこのアーティファクトを参照する方法も調べる

extra_hosts を設定する†

上で runner に extra_hosts を追加している場合には、

runner/config.toml に、

[[runners]]
  [runners.docker]
    extra_hosts = ["myserver.com:192.168.0.2"]

の設定をしないと、runner docker 内部で作成される docker コンテナに hosts の設定が引き継がれないことに注意が必要。

試してみる†

これで始めから npm や playwright の使える環境で ci スクリプトを走らせることができるようになったはず。

上のスクリプトの before_script をバージョン確認だけにしてみた。

default:
  before_script:
    - node --version
    - npm --version

すると、

LANG:console
$ node --version
v20.16.0
$ npm --version
10.8.1

と表示され、残りのスクリプトも正しく実行された。

GitHub のプロジェクトをクローンして GitLab へ登録する†

まず、こちらで作った typescript-vitest-skeleton という GitHub プロジェクトをクローンして、 GitLab へ登録しなおす

https://dora.bk.tsukuba.ac.jp/~takeuchi/?typescript+%2B+vitest+%E3%81%A7+npm+%E3%83%91%E3%83%83%E3%82%B1%E3%83%BC%E3%82%B8%E3%81%AE%E9%96%8B%E7%99%BA+2024

GitLab 上で typescript-vitest-skeleton という空のプロジェクトを作成しておいて、

LANG:console
$ git clone https://github.com/osamutake/typescript-vitest-skeleton.git
Cloning into 'typescript-vitest-skeleton'...
$ cd typescript-vitest-skeleton/
$ npm i
$ git remote add origin2 https://myserver.com/gitlab/myname/typescript-vitest-skeleton.git
$ git push origin2 --all

左のメニューの Deploy - Package Registray からこの GitLab プロジェクトのパッケージレジストリを確認できる。

https://myserver.com/gitlab/myname/typescript-vitest-skeleton/-/packages

当然今は空だ。

ここに上記 npm パッケージを登録したい。

パッケージ名のスコープ†

GitLab プロジェクトのパッケージレジストリへパッケージを登録するには、

https://myserver.com/gitlab/api/v4/projects/(project id)/packages/npm/@(scope_name)/(package_name)

のようなアドレスへパッケージを PUT することになる。

ここで、

• project id : この GitLab サーバーのプロジェクトにつけられた通し番号
  • プロジェクトのトップページ https://myserver.com/gitlab/myname/typescript-vitest-skeleton の右上の縦に３つ並んだ点のアイコン（More actions）をクリックして "Copy Project ID: 9" をクリックするとコピーできる

• scope_name : npm ではパッケージ名の前に @ユーザー名 を付けることでスコープ付きにして、他のパッケージと名前が被らないようにしますが、それと似たような識別子
  • GitLab で使うときは GitLab サーバーを識別するために使うことになるみたい？

• package_name : 例えば上の typescript-vitest-skeleton

まだよくわかっていないのだけれど、どうやら GitLab の提供する npm パッケージサーバーからパッケージをダウンロードさせたい場合「"@osamu_takeuchi/*" のように @osamu_takeuchi というスコープがついているパッケージは npm ではなく特定の GitLab サーバーを探しに行け」という設定をすることになるみたいなので、パッケージ名を例えば @myserver/typescript-vitest-skeleton というような、分かりやすいスコープ付きにしておくのが良さそう？

LANG:console
$ git remote remove origin
$ git remote remove origin2
$ git remote add origin https://myserver.com/gitlab/myname/typescript-vitest-skeleton.git
$ sed -i.bak s/@osamu_takeuchi/@myserver/ package.json 
$ git add package.json
$ git commit -m "Scope of package is changed"
$ git push origin

デプロイ用のトークンを発行して .npmrc を設定する†

パッケージのアップロードには個々のプロジェクトからのアクセス許可が必要なので、

プロジェクトの Settings - Repository - Deploy Tokens - Add token からトークンを発行する。

https://myserver.com/gitlab/myname/typescript-vitest-skeleton/-/settings/repository

GitLab はいろんなところでいろんな用途のトークンを発行できるので、 違うところで違う用途のトークンを発行して設定して、動かないなあ、となることが多い（汗

• Name を npm push とする
• write_package_registry にチェックを入れる
• [Create deploy token] を押す
• 次の画面で gldt-XXXXXXXXXXXXXXXX のようなトークンをコピーする

プロジェクトのフォルダーにこのトークンを指定した .npmrc を作成する。

LANG:console
$ echo ".npmrc" >> .gitignore
$ cat <<"EOS" >.npmrc
//myserver.com/gitlab/api/v4/projects/9/packages/npm/:_authToken=gldt-XXXXXXXXXXXXXXXXX
@myserver:registry=https://myserver.com/gitlab/api/v4/projects/9/packages/npm/
EOS

このファイルを GitLab へアップロードしてしまうと誰でもデプロイできるようになってしまうので、 必ず .gitignore に追加しておく必要がある。

手動でデプロイする†

後は普通に npm publish すればいい。

LANG:console
$ npm publish
npm notice Publishing to https://myserver.com/gitlab/api/v4/projects/9/packages/npm/ with tag latest and default access
+ @myserver/mypackage@0.0.1

これでパッケージがデプロイされ、Package Registry に

@myserver/mypackage (latest)
0.0.1 npm

のような項目が現れる。

TODO: プロジェクトじゃなくグループ単位のレジストリを使った方が良いのかも？

TODO: ci スクリプトから自動的にデプロイする方法は？

特に Deploy Token をどのように CI スクリプトに渡せばいいのかが想像つかない？？？

Package Registry のパッケージを npm install する†