GitLabでPlantUML使ってみる

Top / GitLabでPlantUML使ってみる

[ トップ ]   [ 編集 | 凍結 | 差分 | バックアップ | 添付 | リロード ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

最新の30件

pukiwiki記事一覧

GitLab

目次 †

動機 †

GitLabを立ち上げて、ReadMe?などの閲覧でMarkDown?書いて、そんでもってPlantUml?がmarkdown内に記述できたら、以下のメリットがあるのではないかと思った

メリット †

テキストなので、diffを使った差分がわかるので以下のメリットがある。

• 汎用的なツールで違いを見つけることができる。つまり、低コスト

• 差分だけの確認でよいので、時間の節約

• テキストなので、成果物のファイルサイズが小さくて済むので、マシンリソースの節約

• gitがつかえるので、分散管理でドキュメントの消失に強い

注意点 †

メールサーバを導入しないので以下に示す手順を実行しないとログインできない点に注意する

volumesディレクトリの準備 †

mkdir config
mkdir logs
mkdir data
mkdir gitlab-runner-config

完成版、docker-compose.yaml †

要点:以下の文章で部分的に説明していますが、結局はこれをコピペしてつかってください。

version: "3.9"
services:
  web:
    image: 'gitlab/gitlab-ce:latest'
    restart: always
    hostname: 'gitlab.example.com'
    environment:
      # 初回ログインに利用するrootユーザーのパスワード※簡単だとエラーになる
      GITLAB_ROOT_PASSWORD: "autjg267"
      TZ: "Asia/Tokyo" 
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'http://gitlab1:8929'
        nginx['redirect_http_to_https'] = true
        gitlab_rails['gitlab_shell_ssh_port'] = 2224
        letsencrypt['enable'] = false
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'http://localhost:8929'
        letsencrypt['enable'] = false
        gitlab_rails['omniauth_enabled'] = false
        gitlab_rails['ldap_enabled'] = true
        gitlab_rails['prevent_ldap_sign_in'] = false
        gitlab_rails['ldap_sync_worker_cron'] = "*/5 * * * *"
        gitlab_rails['time_zone'] = 'Asia/Tokyo'
        gitlab_rails['ldap_servers'] = YAML.load <<-EOS
          main:
            label: 'My Ldap'
            host: 'ldap-server'
            port: 389
            uid: 'cn'
            encryption: false
            verify_certificates: false
            bind_dn: 'cn=admin,dc=my-company,dc=com'
            password: 'admin'
            # tls_options:
            # ca_file: ''
            # ssl_version: ''
            # ciphers: ''
            # cert: ''
            # key: ''
            active_directory: false
            allow_username_or_email_login: true
            # root権限ユーザでLDAPユーザが正規かどうかチェックする運用の場合はtrue
            block_auto_created_users: false
            base: 'dc=my-company,dc=com'
            user_filter: ''
            lowercase_usernames: true
            # attributes:
            #   name: 'cn'
            # group_base : 'ou=gitlab_groups,ou=groups,dc=internal'
            # admin_group : 'gitlab_admins'
            # external_groups : []
            # sync_ssh_keys : false
        EOS
    ports:
      - '8929:8929'
      - '2224:22'
      - '443:443'
    volumes:
      - './volumes/gitlab-data/config:/etc/gitlab'
      - './volumes/gitlab-data/logs:/var/log/gitlab'
      - './volumes/gitlab-data/data:/var/opt/gitlab'
    tty: true
  plantuml:
    image: plantuml/plantuml-server
    restart: always
    ports:
      - "8005:8080"
    environment:
      TZ: "Asia/Tokyo" 
  kroki:
    image: 'yuzutech/kroki'
    restart: always
    ports:
      - "8081:8000"
    depends_on:
      - blockdiag
      - mermaid
      - bpmn
      - excalidraw
    environment:
      - TZ="Asia/Tokyo"
      - KROKI_BLOCKDIAG_HOST=blockdiag
      - KROKI_MERMAID_HOST=mermaid
      - KROKI_BPMN_HOST=bpmn
      - KROKI_EXCALIDRAW_HOST=excalidraw
  blockdiag:
    image: yuzutech/kroki-blockdiag
    restart: always
    expose:
      - "8001"
  mermaid:
    image: yuzutech/kroki-mermaid
    restart: always
    expose:
      - "8002"
  bpmn:
    image: yuzutech/kroki-bpmn
    restart: always
    expose:
      - "8003"
  excalidraw:
    image: yuzutech/kroki-excalidraw
    restart: always
    expose:
      - "8004"
  gitlab-runner:
    image: gitlab/gitlab-runner:latest
    container_name: gitlab-runner
    restart: always
    volumes:
      # windows
      - //./pipe/docker_engine:/var/run/docker.sock
      # linux
      # - /var/run/docker.sock:/var/run/docker.sock
      - ./gitlab-runner-config:/etc/gitlab-runner
    ports:
      - "8093:8093"

 ldap-server:
   image: osixia/openldap:latest
   restart: always
   container_name: ldap-server
   environment:
     LDAP_ORGANISATION: "My Company"
     LDAP_DOMAIN: "my-company.com"
     LDAP_ADMIN_PASSWORD: "admin"
     LDAP_READONLY_USER: "true"
     LDAP_READONLY_USER_USERNAME: "readonly"
     LDAP_READONLY_USER_PASSWORD: "readonly_password"
     LDAP_TLS_VERIFY_CLIENT: "never"
   ports:
     - "389:389"
   volumes:
     - ./volumes/openldap/var/lib/ldap:/var/lib/ldap
     - ./volumes/openldap/etc/ldap/slapd.d:/etc/ldap/slapd.d
     - ./openldap/testuser.ldif:/slapd/assets/custome/testuser.ldif

  ldap-admin:
    image: osixia/phpldapadmin:latest
    container_name: ldap-admin
    restart: always
    environment:
      PHPLDAPADMIN_LDAP_HOSTS: "ldap"
      PHPLDAPADMIN_HTTPS: "false"
    ports:
      - "8095:80"
    links:
      - "ldap-server:ldap" 

windowsのWSLのメモリサイズの上限を設定するシェルの例 †

最近のwindows11のバージョンでは、いろいろサーバを立ち上げると、docker desktopがメモリを圧迫したまま開放しない、という仕組みに変わったらしいので、いずれ修正されると思うが、

git for windowsで使う想定で、.wslconfigを修正するスクリプトを書いた。手動のほうが早かったかもしれない。実験でdocker-composeを使った後のメモリ開放設定の後始末用にあると自動化できて便利かもしれないから残しておきます。

#!/bin/bash

# 設定したいメモリのサイズ (例: 8GB)
MEMORY_SIZE="8GB"

# .wslconfigファイルのパス
WSLCONFIG_PATH="/c/Users/(自分のログインユーザのディレクトリ)/.wslconfig"

# .wslconfigファイルが存在するか確認
if [ -f "$WSLCONFIG_PATH" ]; then
    # ファイルが存在する場合、memory設定を更新
    sed -i "s/^memory=.*$/memory=$MEMORY_SIZE/" $WSLCONFIG_PATH
else
    # ファイルが存在しない場合、新規作成してmemory設定を追加
    echo -e "[wsl2]\nmemory=$MEMORY_SIZE" > $WSLCONFIG_PATH
fi

何がしたいのかというと単純に.wslconfigというファイル名で、上記のdocker-compose.ymlで起動するサーバのメモリをwindowsで上限付きで確保しておきたいというだけです。ちなみに.wslconfigファイルは以下のようになります。

[wsl2]
memory=8GB

Docker Desktopの再起動 †

上記のメモリの上限せっていはwindows11の特定のバージョンでしか使わないとはおもいますが、その設定を行った後は、以下のコマンドで再起動します。もちろん手動でも全然大丈夫です。

# wslのシャットダウン
wsl --shutdown
# Docker Desktop起動
"C:\Program Files\Docker\Docker\Docker Desktop.exe" &

GitLabをDockerをつかってインストール †

公式サイトの以下のページを見る

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

インストール方法はたくさんあるが、今回はdockerを使ったやり方にする

ローカルサーバとしてたちあげてみるだけなので、メールの認証とかの設定は行わず、rubyのインタプリタツールを直接触って、サーバに直接パスワードを書き込む方式とする。

dockerを利用したGitLabのインストール †

今回は、どの環境でも素早く構築できることを信じてDockerでインストールする方法をためしてみようと思う。

https://docs.gitlab.com/ee/install/docker.html

Docker for Windows は公式にはサポートされていないようだ。でもやりたいのは、ローカルマシンのwindows上で動作させることだからなんとかやってみる。

成功事例の以下のブログ記事を参考にしてみよう。

Windows10にDocker ComposeでGitlabを導入 †

https://qiita.com/peanuts2013/items/105be140eb9826cfdb2d

Windows＋Docker(Compose)でGitlabをローカルに立ち上げた時の話 †

https://qiita.com/beeeegle/items/b8d8da113f272f61af44

gitlabのDockerイメージ †

https://hub.docker.com/r/gitlab/gitlab-ee/

いや、まてよコミュニティーエディションは、こっちか https://registry.hub.docker.com/r/gitlab/gitlab-ce/

こっちがコミュニティーエディションのほうが無料のはず。まあ、そんなことは気にしなくても、dockerを使ったインストールのブログをあされば、docker-composeの設定が書いてあるとおもうから、それをつかえばいい。

機能の比較 †

https://about.gitlab.com/features/?stage=plan

無料で使える機能が充実している、よっぽど使い倒す気持ちがない以上は無料プランでよいとおもった。

JIRAとも連携できるのか、ふむふむ。

手順 †

端末のIPアドレスを調べる †

ipconfig -all

hostsファイルにローカルのIPアドレスの別名を登録しておく †

以下の説明では、調べたIPアドレスを以下名前でhostsファイルに登録したものとする

調べたIPアドレス gitlab1

保存すると、すぐに適用されるようだ

なぜこうするかというと、 †

• wifi接続のローカルのマシンだとIPアドレスが不安定だし、macアドレスで固定するにしても、会社の環境だとルータの設定さわらせてくれないことも考えられる。
• localhostを使う場合だと、他の同じwifi接続のマシンから見たときにplantumlサーバがlocalhostになってしまって、うまくplantumlの画像が生成されない。

だから、IPアドレスが変更になってしまっても、最小限の修正で復帰できて、他サーバからもアクセス可能にするためにhostsをつかう運用が良いのだ。

手順2 gitlabとplantumlサーバを立ち上げる †

以下のコマンドで、上記で設定したdocker-compose.ymlで設定した内容でdockerが起動する。

docker-compose up -d

起動には数分かかる。起動中は以下のコマンドでstartingと表示される

docker-compose ps

起動が完了すると

healty

という状態になる。

docker-compose.ymlのvolume:で指定したディレクトリにgitlabのファイルが共有されるようになる。

手順3 gitlabの設定ファイルにplantumlサーバとのリダイレクト設定できるように設定を追記 †

設定を反映させる †

# 立ち上がっているdockerのコンテナ名を調べる
docker-compose ps

# コンテナに接続
docker exec -it コンテナ名 bash

gitlabからplantumlへは、gitlab内のnginxサーバのプロキシ設定を以下の設定を追記することで行う。

参考: https://docs.gitlab.com/ee/administration/integration/plantuml.html

ファイル名：/etc/gitlab/gitlab.rb †

# Docker deployment
nginx['custom_gitlab_server_config'] = "location /-/plantuml/ { \n proxy_cache off; \n    proxy_pass  http://gitlab1:8080/; \n}\n"

捕捉：ここで躓く人は、以下のサイトを見るといいのかもしれない。

https://qiita.com/RYO-4947123/items/cf138989eebf12e45601

# 設定を反映させる
gitlab-ctl reconfigure

手順4 Adminでログインできるように直接パスワードを登録する †

ldapサーバを使わない場合の手順である。ほかのサービスも立ち上げる場合はLADPサーバを使えるように設定するのが良いと思う。

参考: https://e-penguiner.com/gitlab-with-docker-onpremise/

立ち上がっているGitLabにbashで接続する †

rubyのツールを立ち上げる †

dockerコンテナ内のbash上で以下のコマンドを打つ

gitlab-rails console -e production

※起動には数分かかります

手順5 ログインできるようにする。 †

gitlabのdocker版はメールサーバまでは入っていない。設定方法は有るらしいが、 数人で使う程度ならば、パスワードはgitlabに以下に示す手作業でいれることができる。

rubyのインタプリタが動作するのでパスワードを設定する †

user = User.where(id: 1).first

user.password='設定したいパスワード'

user.password_confirmation='設定したいパスワード'

user.save!

exit

gitの管理者でログイン †

ユーザを追加する前に、root権限でログインしておく

以下の手順で認証のメールが必要な手続きをしないようにしておく

• メインメニュー [管理者]をクリック

• 設定 [全般的]をクリック

• Sign-up restrictions [Expand]をクリック

• "Require admin approval for new sign-ups"のチェックをはずす

これで、ユーザ追加後にログインできるようになった。

rootユーザ以外の場合 †

ユーザ登録をすると、パスワードがランダムに割り振られるので、上記の

user = User.where(id: 1).first

の数値1を適宜増やしてパスワードを直接いれて保存するのがよいと思う。

ただし、パスワードをいれたあと、以下の設定が無いとログインができない。

GitLabでPlantUml?を使う手順 †

plantumlをgitlabで使うには、設定で有効にしないといけない

手順 †

Main menu の Adminをクリック

Settings の Generalをクリック

PlantUML セクションを広げる

Enable PlantUML のチェックボックスをオンにする

URLには、http://gitlab1:8005 と入れる

参考：gitlabのplantuml設定を有効にする　 †

https://docs.gitlab.com/ee/administration/integration/plantuml.html#configure-your-plantuml-server

SSHキーの登録 †

参考: https://click.jp/knowledge/1476/

手順 †

もし、git for windowsをインストールしていない場合はインストールする

もし、まだ公開鍵がない場合は以下の手順で作る

以下の"ホームディレクトリ"は各自の環境のホームディレクトリに読み替えて実行されたい

git for windowsのシェルでログインした直後という前提で説明する

# ホームディレクトリに移動
cd ~

mkdir .ssh

cd .ssh

ssh-keygen

あとはエンターキー

すると、ファイルが２つできる。

# 生成されたファイルを確認
ls

拡張子がpubのファイルがあったとする。

なんとか.pub

そのファイルの中身をコピペしたいので

cat なんとか.pub

とすると鍵の内容がわかるので、それをコピーする。

gitlabでプロジェクトをつくったとしたら、"ADD SSH-KEY"ボタンをクリックする

先ほどコピーしたなんとか.pubの中身を張り付ける。

これで、

git pull

や

git push

ができるようになる。

krokiも使えるようにしてみる †

上記のplantumlの追加だけでも十分なのだが、ついでにkrokiも使えるようにしておく。

C4とかBPMNとか使ってみたい。

GitLabの設定参考URL: https://docs.gitlab.com/ee/administration/integration/kroki.html

docker-compose.ymlに追加する †

以下をdocker-compose.ymlに追加する。軽く説明すると、krokiのコアを呼ぶけど、いろいろなマークダウン風の出力を提供しているサーバのdockerたちに依存してるよ。

ぐらいの意味である。

  kroki:
    image: 'yuzutech/kroki'
    ports:
      - "8081:8000"
    depends_on:
      - blockdiag
      - mermaid
      - bpmn
      - excalidraw
    environment:
      - TZ="Asia/Tokyo"
      - KROKI_BLOCKDIAG_HOST=blockdiag
      - KROKI_MERMAID_HOST=mermaid
      - KROKI_BPMN_HOST=bpmn
      - KROKI_EXCALIDRAW_HOST=excalidraw
  blockdiag:
    image: yuzutech/kroki-blockdiag
    expose:
      - "8001"
  mermaid:
    image: yuzutech/kroki-mermaid
    expose:
      - "8002"
  bpmn:
    image: yuzutech/kroki-bpmn
    expose:
      - "8003"
  excalidraw:
    image: yuzutech/kroki-excalidraw
    expose:
      - "8004" 

ポートの8081が、こちらから使うポートになるので、番号が他のdockerで立ち上げたサーバとかぶらないようにしよう。

参考にさせていただいたURL †

https://www.rk-k.com/archives/4399

GitLabの設定 †

plantumlのときで出てきた設定項目の２，３個上にkrokiの設定がある。

サーバのアドレスをgitlab1にしていれば、以下のリンクからでも設定画面に行くと思う。

http://gitlab1:8929/admin/application_settings/general#js-kroki-settings

チェックボックスをオンにする。

URLには、

http://gitlab1:8081

をいれる

krokiの追加フォーマット扱い †

公式の解説URL: https://docs.kroki.io/kroki/setup/install/#images

たとえば、BPMNを有効にしてみる †

そこには、Companion containers という欄にBPMN

が書いてあって、リンクをたどると、Dockerのページに飛ぶ。ちなみにURLは以下

https://hub.docker.com/r/yuzutech/kroki-bpmn

そこには、dockerのpullコマンドが下記のように書いてあった。

docker pull yuzutech/kroki-bpmn

LDAPサーバを使う場合の設定 †

参考： https://qiita.com/hiren/items/cba9fc6da7165c9416a0

DN（Distinguished Name）について †

LDAPでは、各エントリ（オブジェクト）を一意に識別するためにDN（Distinguished Name）という形式を使用します。DNは、ツリー構造を辿ってエントリを特定するためのパスのようなものです。

DNは逆順で記述され、コンマで区切られます。各コンポーネントは属性=値の形式で記述されます。たとえば、cn=John Doe,ou=Marketing,dc=example,dc=comというDNは、example.comドメインのMarketing組織単位（OU）に属するユーザーJohn Doeを表しています。

• dc=example,dc=com: ドメインコンポーネント（dc）は、LDAPツリーの最上位に位置し、通常は企業や組織のインターネットドメイン名を表します。
• ou=Marketing: 組織単位（ou）は、組織内の部門やグループを表します。
• cn=John Doe: 共通名（cn）は、エントリの一意の識別子を表します。ユーザーの場合はユーザー名やフルネームが使われます。

baseパラメータについて †

LDAP設定のbaseパラメータに設定するDNは、ユーザー検索を開始する基点となるDNを指定します。したがって、GitLabがLDAPサーバでユーザーを検索する際には、このbaseDNから下のツリー構造を探索します。

設定を反映させる †

docker-compose exec web gitlab-ctl reconfigure

LADPでのユーザ登録 †

ldifファイルの作成 †

LDIF（LDAP Data Interchange Format）は、LDAPエントリを表現するための標準的な形式です。エントリ（ユーザーやグループなど）を追加、変更、削除するために使用されます。

• dn: Distinguished Name（識別名）で、LDAPディレクトリ内のエントリの一意なパスを示します。

• changetype: このエントリに対する操作のタイプを示します。ここでは新しいエントリを追加するため、addが指定されています。

• objectClass: エントリのタイプを定義するスキーマを示します。複数のobjectClassが存在する場合、そのエントリはすべてのobjectClassの特性を持ちます。

• uid: ユーザーIDを示します。

• cn: 共通名を示します。通常はフルネームです。

• sn: サーネーム（姓）を示します。

• o: organization（組織）を示します。

• userPassword: ユーザーのパスワードを格納します。 {SSHA}wvxuaDL+/m3phJE6fyrtGU8UODCfjA2iはハッシュ化されたパスワードを表しています。

ldifの例 †

mkdir openldap
cd openldap
vi testuser.ldif

testuser.ldif †

dn: cn=test001,dc=my-company,dc=com
givenName: test001
sn: test001
cn: test001
mail: test001@my-company.com
userPassword: dGVzdDAwMQ=a
objectClass: inetOrgPerson
objectClass: top

dn: cn=test002,dc=my-company,dc=com
givenName: test002
sn: test002
cn: test002
mail: test002@my-company.com
userPassword: dGVzdDAwMg==
objectClass: inetOrgPerson
objectClass: top

暗号化されたパスワードを用いる例 †

userPassword: {SSHA}wvxuaDL+/m3phJE6fyrtGU8UODCfjA2i
mail: test.user@example.co.jp

上記の {SSHA}は、パスワードがソルト付きのSHA（Secure Hash Algorithm）でハッシュ 化されていることを示しています。

のハッシュ値を生成するには特殊なツールが必要で、例えば slappasswd コマンド（OpenLDAPの一部）がよく使われます。以下のように使用します：

slappasswd -h {SSHA} -s yourpassword

このコマンドは、入力されたパスワード（この場合は yourpassword）に対するSSHAハッシュを出力します。この出力値をLDIFファイルの userPassword フィールドに設定します。

gitlabの電子メールの取り扱いについて †

LDAP 電子メール属性が GitLab ユーザー データベースに見つからない場合は、新しいユーザーが作成されます。

すでに、Gitlabにユーザが登録されている場合は、電子メールアドレスが LDAP 電子メールアドレスと一致する必要があります。

• uid: ユーザーがサインインに使用するユーザー名にマップする LDAP 属性。 にマップする値ではなく、属性である必要がありますuid。GitLab ユーザー名には影響しません

追加 †

上記の場合だと、
docker exec -it ldap-server bash
ldapadd -x -D "cn=admin,dc=my-company,dc=com" -w admin -f /slapd/assets/custome/testuser.ldif -ZZ

# ldapadd -x -D "cn=Manager,dc=example,dc=co,dc=jp" -W -f /tmp/user1.ldif
Enter LDAP Password:
adding new entry "uid=12345, ou=people, dc=example, dc=co, dc=jp"

確認 †

# slapcat

(略)

dn: uid=12345,ou=people,dc=example,dc=co,dc=jp
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: 12345
cn: Test User
sn: user
o: people
userPassword:: e1NTSEF9d3Z4dWFETCsvbTNwaEpFNmZ5cnRHVThVT0RDZmpBMmk=
structuralObjectClass: inetOrgPerson
entryUUID: a88737f8-8f58-1035-832a-fbe69abdd39f
creatorsName: cn=Manager,dc=example,dc=co,dc=jp
createTimestamp: 20160405090058Z
entryCSN: 20160405090058.799276Z#000000#000#000000
modifiersName: cn=Manager,dc=example,dc=co,dc=jp
modifyTimestamp: 20160405090058Z

参考にしたサイト †

OpenLDAPサーバーで、ユーザーを追加 †

https://qiita.com/gigatune/items/23439fa02488a626c3d4

Integrate LDAP with GitLab †

https://docs.gitlab.com/ee/administration/auth/ldap/?tab=Docker#attribute-configuration-settings

LDAP_INVALID_CREDENTIALS 49 †

openldapのコンテナにdocker execコマンドで入って以下のコマンドを打つ

slapcat

結果 †

root@87bced4a4861:/# slapcat
dn: dc=example,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: Example Organization
dc: example
structuralObjectClass: organization
entryUUID: 62fba352-8719-103d-94d5-97c5167399a0
creatorsName: cn=admin,dc=example,dc=com
createTimestamp: 20230515030735Z
entryCSN: 20230515030735.894048Z#000000#000#000000
modifiersName: cn=admin,dc=example,dc=com
modifyTimestamp: 20230515030735Z

LDAPは、ログインIDだけではダメで、dcの値も入れないといけない。例えていうならば、自分の名前だけでログインはできず、住所を述べてそのあとで名前を入れないといけない感じ

対策 †

docker-composeで初回に設定した内容で、設定フォルダなどができてしまい、それが残っている場合は、いったん設定フォルダをクリアすると、自分の場合は解消した。

参考になったURL †

https://hatman62.hatenablog.com/entry/2016/06/08/230701

• docker コンテナで構築するGitlabでLDAP連携（OpenLDAP）する方法 https://qiita.com/v1tam1n/items/2b780fa7fb6ae133bf8b

       

Last-modified: 2023-05-16 (火) 11:54:02 (345d)

Link: GitLab(539d)

Web Master: hayashi_kuniyuki

PukiWiki 1.4.7 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji. Powered by PHP 5.3.29. HTML convert time: 0.034 sec. skin apricot by hirokasa