What's New Qiita

20200917のdockerに関する記事は7件です。

  • 投稿日：2020-09-17T22:02:24+09:00

Docker run コマンドを分解すると。。。

Docker runコマンドを分解すると

docker run　#イメージを取得して、イメージからコンテナを起動するコマンド

以下の三つのコマンドの処理が順に実行することと同じ処理になる。

docker pull #イメージの取得

docker create #コンテナの作成

docker start #コンテナの起動

Docker run コマンドは便利！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-17T21:57:26+09:00

yarn install に失敗する "getaddrinfo EAI_AGAIN registry.yarnpkg.com"

本記事は Docker Toolbox を対象としています。Docker for Windows は対象外

Docker が build できない

webアプリ開発のためテストサーバを docker 上にビルドしようとしたら失敗した。 

Step 10/11 : RUN cd app && yarn install
 ---> Running in d36ecd97329b
yarn install v1.22.4
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/chalk/-/chalk-2.4.2.tgz: getaddrinfo EAI_AGAIN registry.yarnpkg.com".

以下が問題のファイル

Dcokerfile
FROM node:12.16-slim

ENV APP_DIR=/app
WORKDIR ${APP_DIR}
RUN mkdir -p ${APP_DIR}
COPY . ${APP_DIR}

ENV LANG=C.UTF-8
ENV TZ=Asia/Tokyo
ENV NODE_ENV=development
ENV HOST 0.0.0.0

RUN cd app && yarn install

EXPOSE 3000

環境

  • Windows 10 Home 64bit
  • Docker version 19.03.1

Windows 10 Home では Hyper-V が使用できないため DockerToolbox 経由でインストール

原因

registry.yarnpkg.com　の名前解決ができないのは直ぐに分かる。しかし何故？普通にコマンドラインから nslookup できるぞ？と思ったら VirtualBox 側の DNS に問題があるようだ。Linux カーネルを用意するため OS とコンテナの間に挟まっており、意外と問題を見落としやすい。VirtualBox 上で叩くと、

dcoker@default:~$ nslookup registry.yarnpkg.com
Server:    10.0.2.3
Address 1: 10.0.2.3
nslookup: can't resolve 'registry.yarnpkg.com'

解決手法

手っ取り早く DNS サーバに8.8.8.8をセカンダリーに追加する。

dcoker@default:~$ sudo -i
root@default:~# vi /etc/resolv.conf

DNS設定【resolv.conf 】再起動後の上書きを無効化する

/etc/resolv.conf
  nameserver 10.0.2.3
+ nameserver 8.8.8.8

8.8.8.8 は Google Public DNS のアドレスで、DNSで困った時の頼もしい味方。
キーボード配列の違いでコロン:が打てず vi 終了できない！そんなJIS配列ユーザのあなたは'+' (Shift + ';')を押下しましょう。

[Qiita] JISキーボードなのにUS配列の環境で文字を打つ

これは応急処置なので、VirtualBox を再起動すると元に戻るなど恒久的な解決にはならないので注意。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-17T17:46:56+09:00

社外接続できない素のRHEL7サーバーにDb2 WarehouseコンテナをSMP構成でデプロイする

はじめに

Db2 Warehoue はコンテナベースのアーキテクチャによって環境やOSを選ばず、迅速にデプロイできるという特徴を備えています。Db2 Warehoueを勤務先のサーバーに導入しましたが、導入対象となったサーバーでは社外サイトに接続できないという制約がありました。社内ネットワークには接続できます。Db2 Warehouseのデプロイ自体は早く済ませることができますが、準備に手間を要しました。

本記事ではネットワーク接続有り、ただし外部接続不可、といった状況での導入方法をまとめます。特にDockerを導入する時にオフラインでyumを使うためのリポジトリ設定がポイントとなります。Dockerのリポジトリを作成し、さらに各種ライブラリを保持するリポジトリを導入対象サーバー内に作成します。

前提事項

導入対象の環境は次の通りです。

  • Red Hat Enterprise Linux (RHEL) 7.8 x86_64

ここにDockerを導入し、Db2 Warehouseコンテナをデプロイします。Dockerについては、無料の community edition を使います。

  • Docker Community Edition (Docker CE) 19.03.9
  • Db2 Warehoue Enterprise Edition 11.5.4

なお、Docker HubにDb2 Warehoue Developer Edition v11.5.2が登録されていますが、2020年3月をもってサポートが終わっています。Db2 WarehouseのパッケージはIBMサイトから4節に記載の方法で取得して下さい。

参考資料

導入の流れ

  1. 前提条件の確認
  2. yumローカルリポジトリ作成
  3. Dockerエンジンの導入
  4. Db2 Warehouseコンテナイメージの取得
  5. Db2 Warehouseコンテナのデプロイ

1. 前提条件の確認

1.1 Docker CEが動作するための前提

Dockerの対応プラットフォームの一覧表を見るとRHELに対応していないことがわかります。ですが、CentOSがサポートされているので、よしとします。

1.2 Db2 Warehouseが動作するための前提

IBM Knowledge CenterのLinux および x86 ハードウェアでの IBM Db2 Warehouse の前提条件にもとづいて確認します。

1.2.1 ハードウェアの前提

  • プロセッサー：2.0GHz
    cat /proc/cpuinfoで確認できます。

  • メモリー：8GB
    cat /proc/meminfoで確認できます。

  • ストレージ：25GB (開発環境での最小)
    df -hで確認できます。オプションの -h によってサイズを示す数字にMやGといった単位が付きます。

1.2.2 ファイルシステムの前提

  • POSIX 準拠のファイル・システム

RHELのデフォルトファイルシステムであるxfsはPOSIX準拠であり、次のように/がxfsであることが確認できます。(RHEL8のマニュアルにPOSIX準拠と記載されていますが、RHEL7でも同様です)

[root@rhel1 ~]# df -T
ファイルシス            タイプ   1K-ブロック     使用    使用可 使用% マウント位置
（中略）
/dev/mapper/rhel00-root xfs        287378332 14130424 273247908    5% /

1.2.3 ネットワークの前提

  • ノード・ホストが/etc/hostsに登録されていること
    • 登録されていない場合は、次の最下行のように登録してください。
/etc/hostsの内容
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
xxx.xxx.xxx.xxx    rhel1.myhome.com    rhel1
  • IPv4 転送が有効になっていること
    • /etc/sysctl.conf に次の最後の行を追加します。
/etc/sysctl.conf
# sysctl settings are defined through files in
（中略）
net.ipv4.ip_forward=1

  • ポートが開いていること

    • 次のポートがFirewalldでふさがれていないことを確認します。
      • 60000 から 60060: データベース FCM 用 (HADR を使用する場合は、60006 から 60007 が HADR 用)
      • 32768 から 65535: FCM 接続テスト用
      • 25000 から 25999: Apache Spark 用
      • 50022: 自動化と管理のための SSH 用
      • 50001: SSL を使用するデータベース接続用
      • 50000: SSL を使用しないデータベース接続用
      • 9929: 通信テスト用
      • 9300: Web コンソールの状況確認用
      • 8998: Livy サーバー経由の Apache Spark アプリケーション・ジョブの実行用
      • 8443: Web コンソールの HTTPS 用
      • 5000: システム・マネージャー用
      • 2379 - 2380: HA 管理用
      • 389: LDAP 用
      • 22: SSH/ホスト・オペレーティング・システム用
    • firewalldが動いているのかどうかをfirewall-cmd --stateで確認し、止まっていればsystemctl start firewalldで起動します。次に許可されているポートを確認します。
[root@rhel1 ~]# firewall-cmd --list-ports
60000-60060/tcp 25000-25999/tcp 50022/tcp 50001/tcp 50000/tcp 9929/tcp 9300/tcp 8998/tcp 8443/tcp 5000/tcp 2379-2380/tcp 389/tcp 22/tcp 60000-60060/udp

上のようにポートが表示されなければ許可されていないため、次のコマンドでポートを開けます。
- 参考：IBM Db2 Warehouse のトラブルシューティングの「デプロイメント中にポート検査が失敗する」

firewall-cmd --zone=public --add-port=60000-60060/tcp --permanent ; 
firewall-cmd --zone=public --add-port=25000-25999/tcp --permanent ;
firewall-cmd --zone=public --add-port=50022/tcp --permanent ;
firewall-cmd --zone=public --add-port=50001/tcp --permanent ;
firewall-cmd --zone=public --add-port=50000/tcp --permanent ;
firewall-cmd --zone=public --add-port=9929/tcp --permanent ;
firewall-cmd --zone=public --add-port=9300/tcp --permanent ;
firewall-cmd --zone=public --add-port=8998/tcp --permanent ;
firewall-cmd --zone=public --add-port=8443/tcp --permanent ;
firewall-cmd --zone=public --add-port=5000/tcp --permanent ;
firewall-cmd --zone=public --add-port=2379-2380/tcp --permanent ; 
firewall-cmd --zone=public --add-port=389/tcp --permanent ;
firewall-cmd --zone=public --add-port=22/tcp --permanent ;
firewall-cmd --zone=public --add-port=60000-60060/udp --permanent ; 
firewall-cmd --reload

1.2.4 Dockerに関する前提

  • v17.06 の Docker エンジン (Enterprise Edition (EE) または Community Edition (CE))であること

    • 本記事では Docker CE v19.03.9 を使います。

  • ストレージ・ドライバーとしてoverlay2が推奨です。これは複数のファイルシステムを1つにマージするUnionFSというファイルシステムに由来を持ち、高速化されたものです。

    • 本記事ではoverlay2を使います。その設定はDocker CE導入後に行うため、説明も後で述べます。
    • 推奨ドライバーのことは IBM Knowledge Center の英語版、Db2 Warehouse deployment planning > Prerequisites > Linux and x86 hardwareのDocker prerequisites節に記載されています。
    • IBM Knowledge Center の日本語版ではdevicemapperを使うように記載されています。私が試したところ、devicemapperに対してDb2 Warehouseコンテナを導入することができましたが、コンテナを起動するときに次の警告が表示されます。
      • The recommended Docker storage driver for IBM Db2 Warehouse is overlay2.

2. yumローカルリポジトリ作成

作業の流れは次のようになります。

2.1 RHEL binary DVD isoファイルの取得
2.2 RHELのローカルリポジトリ作成
2.3 Docker CEパッケージファイルの取得
2.4 Docker CEのローカルリポジトリ作成

2.1 RHEL binary DVD isoファイルの取得

外部サイトにアクセスできる環境であれば、Docker CE導入時に必要となる各種パッケージをyumが自動的に取得します。本記事では外部サイトの代わりに、RHELのDVD isoファイルから各種パッケージを取得するように設定します。外部接続できる環境を使って、Redhat社のページからDVD isoファイルをダウンロードします。（ユーザー登録が必要です）

2.2 RHELのローカルリポジトリ作成

RHELのDVD isoファイルをマウントします。

[root@rhel1 ~]# ls rhel-server-7.8-x86_64-dvd.iso
rhel-server-7.8-x86_64-dvd.iso
[root@rhel1 ~]# mkdir /mnt/iso
[root@rhel1 ~]# mount -t iso9660 rhel-server-7.8-x86_64-dvd.iso /mnt/iso
mount: /dev/loop0 is write-protected, mounting read-only

DVD isoファイル内のリポジトリ設定ファイルmedia.repoにmediaidが記載されています。これをこの後の手順で別のリポジトリ設定ファイルにコピーします。

/mnt/iso/media.repo
[InstallMedia]
name=Red Hat Enterprise Linux 7.8
mediaid=xxxxxxxxxx.xxxxxx
（以下略）

次の内容でリポジトリ設定ファイルredhat.repoを作成します。ここに上のmediaidを記入します。

/etc/yum.repos.d/redhat.repo
[RHEL7-DVD-Server]
mediaid=xxxxxxxxxx.xxxxxx
name=Red Hat Enterprise Linux 7.8
baseurl=file:///mnt/iso
enabled=1
gpgcheck=1
gpgkey=file:///mnt/iso/RPM-GPG-KEY-redhat-release

2.3 Docker CEパッケージファイルの取得

2.3.1 Dockerサイトから取得

Docker導入済で外部接続できる環境を使ってファイルを3本ダウンロードします。それを導入対象サーバーにアップロードしてホームディレクトリなどに保存します。この記事では導入対象サーバーの/root/DockerRepoに保存するものとします。

2.3.2 CentOSサイトから取得

さらに、次の場所からcontainer-selinuxパッケージをダウンロードして、上と同じ/root/DockerRepoに保存します。

container-selinuxパッケージが欠けていると、Docker CE導入時にそれを要求するエラーが起きます。

[root@rhel1 ~]# yum install docker-ce docker-ce-cli containerd.io
（中略）
--> 依存性解決を終了しました。
エラー: パッケージ: containerd.io-1.2.13-3.2.el7.x86_64 (docker-ce-stable)
             要求: container-selinux >= 2:2.74
エラー: パッケージ: 3:docker-ce-19.03.12-3.el7.x86_64 (docker-ce-stable)
             要求: container-selinux >= 2:2.74
 問題を回避するために --skip-broken を用いることができます。
 これらを試行できます: rpm -Va --nofiles --nodigest

2.4 Docker CEのローカルリポジトリ作成

2.4.1 Dockerのリポジトリ作成

直前の手順によって/root/DockerRepoにDockerパッケージ4本が保存されました。

[root@rhel1 ~]# ls /root/DockerRepo/
container-selinux-2.119.2-1.911c772.el7_8.noarch.rpm  docker-ce-19.03.9-3.el7.x86_64.rpm
containerd.io-1.2.6-3.3.el7.x86_64.rpm                docker-ce-cli-19.03.9-3.el7.x86_64.rpm

次のコマンドでリポジトリを作成します。その結果/root/DockerRepo/repodataが作成されます。

[root@rhel1 ~]# createrepo --database /root/DockerRepo
Spawning worker 0 with 1 pkgs
（中略）
Spawning worker 31 with 0 pkgs
Workers Finished
Saving Primary metadata
Saving file lists metadata
Saving other metadata
Generating sqlite DBs
Sqlite DBs complete

次の内容でリポジトリ設定ファイルdocker.repoを作成します。

/etc/yum.repos.d/docker.repo
[DockerRepo]
name=Yum repository of Docker
baseurl=file:///root/DockerRepo

2.4.2 Dockerの公開鍵登録

次のURLから公開鍵をダウンロードして/etc/pki/rpm-gpg/にRPM-GPG-KEY-docker-centosという名前で保存します。（ファイル名は任意です）
- https://download.docker.com/linux/centos/gpg
保存した鍵をrpmにimportして、結果を確認します。

[root@rhel1 ~]# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-docker-centos
/etc/pki/rpm-gpg/RPM-GPG-KEY-docker-centos

[root@rhel1 ~]# rpm -qi gpg-pubkey-* | grep Summary
（中略）
Summary     : gpg(Docker Release (CE rpm) <docker@docker.com>)

なお、鍵がrpmに登録されていないと、Docker CE導入時に次のようなエラーが起きます。

[root@rhel1 ~]# yum install docker-ce docker-ce-cli containerd.io
（中略）
warning: /root/DockerRepo/docker-ce-cli-19.03.9-3.el7.x86_64.rpm: Header V4 RSA/SHA512 Signature, key ID 621e9f35: NOKEY
docker-ce-cli-19.03.9-3.el7.x86_64.rpm の公開鍵がインストールされていません

3. Dockerエンジンの導入

作業の流れは次のようになります。

3.1 Docker CEの導入
3.2 Docker CEの動作確認
3.3 Docker CEの設定

3.1 Docker CEの導入

次のコマンドを実行して導入します。

[root@rhel1 ~]# yum install docker-ce docker-ce-cli containerd.io
読み込んだプラグイン:langpacks, product-id, search-disabled-repos, subscription-manager

This system is not registered with an entitlement server. You can use subscription-manager to register.

依存性の解決をしています
--> トランザクションの確認を実行しています。
---> パッケージ containerd.io.x86_64 0:1.2.6-3.3.el7 を インストール
--> 依存性の処理をしています: container-selinux >= 2:2.74 のパッケージ: containerd.io-1.2.6-3.3.el7.x86_64
---> パッケージ docker-ce.x86_64 3:19.03.9-3.el7 を インストール
---> パッケージ docker-ce-cli.x86_64 1:19.03.9-3.el7 を インストール
--> トランザクションの確認を実行しています。
---> パッケージ container-selinux.noarch 2:2.119.2-1.911c772.el7_8 を インストール
--> 依存性解決を終了しました。

依存性を解決しました

================================================================================================================================
 Package                         アーキテクチャー     バージョン                                 リポジトリー              容量
================================================================================================================================
インストール中:
 containerd.io                   x86_64               1.2.6-3.3.el7                              DockerRepo                26 M
 docker-ce                       x86_64               3:19.03.9-3.el7                            DockerRepo                24 M
 docker-ce-cli                   x86_64               1:19.03.9-3.el7                            DockerRepo                38 M
依存性関連でのインストールをします:
 container-selinux               noarch               2:2.119.2-1.911c772.el7_8                  DockerRepo                40 k

トランザクションの要約
================================================================================================================================
インストール  3 パッケージ (+1 個の依存関係のパッケージ)

総ダウンロード容量: 88 M
インストール容量: 359 M
Is this ok [y/d/N]: y
Downloading packages:
--------------------------------------------------------------------------------------------------------------------------------
合計                                                                                            243 MB/s |  88 MB  00:00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  インストール中          : 2:container-selinux-2.119.2-1.911c772.el7_8.noarch                                              1/4
  インストール中          : containerd.io-1.2.6-3.3.el7.x86_64                                                              2/4
  インストール中          : 1:docker-ce-cli-19.03.9-3.el7.x86_64                                                            3/4
  インストール中          : 3:docker-ce-19.03.9-3.el7.x86_64                                                                4/4
  検証中                  : 1:docker-ce-cli-19.03.9-3.el7.x86_64                                                            1/4
  検証中                  : 3:docker-ce-19.03.9-3.el7.x86_64                                                                2/4
  検証中                  : containerd.io-1.2.6-3.3.el7.x86_64                                                              3/4
  検証中                  : 2:container-selinux-2.119.2-1.911c772.el7_8.noarch                                              4/4
RHEL7-DVD-Server/productid                                                                               | 1.6 kB  00:00:00

インストール:
  containerd.io.x86_64 0:1.2.6-3.3.el7       docker-ce.x86_64 3:19.03.9-3.el7       docker-ce-cli.x86_64 1:19.03.9-3.el7

依存性関連をインストールしました:
  container-selinux.noarch 2:2.119.2-1.911c772.el7_8

完了しました!

3.2 Docker CEの動作確認

hello-worldコンテナを用いてDocker CEの動作確認を行います。Docker導入済で外部サイトにアクセスできる環境を使ってhello-worldコンテナを取得します。

他環境> docker save hello-world -o hello-world.tar

これをサーバーにアップロードして、ロードできていることを確認し、コンテナを実行します。

[root@rhel1 ~]# docker load -i hello-world.tar
9c27e219663c: Loading layer [==================================================>]  15.36kB/15.36kB
Loaded image: hello-world:latest

[root@rhel1 ~]# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
hello-world         latest              bf756fb1ae65        8 months ago        13.3kB

[root@rhel1 ~]# docker run hello-world
Hello from Docker!
This message shows that your installation appears to be working correctly.
（以下略）

3.3 Docker CEの設定

ストレージドライバーとしてoverlay2を用いるようにDockerを設定します。

3.3.1 バックアップ

ドライバーの変更前に/var/lib/dockerをバックアップします。

[root@rhel1 ~]# systemctl stop docker
[root@rhel1 ~]# cp -au /var/lib/docker /var/lib/docker.bk

3.3.2 overlay2ドライバーの設定

次の内容をdocker deamonの設定ファイルに記入します。

/etc/docker/daemon.json
{
  "storage-driver": "overlay2"
}

3.3.3 overlay2ドライバーの確認

Dockerを起動して、overlay2が使われることを確認します。下から3行目にドライバーがoverlay2であると表示されています。

[root@rhel1 ~]# systemctl start docker

[root@rhel1 ~]# docker info
Client:
 Debug Mode: false
Server:
 Containers: 3
  Running: 0
  Paused: 0
  Stopped: 3
 Images: 2
 Server Version: 19.03.9
 Storage Driver: overlay2
  Backing Filesystem: xfs
（以下略）

なお、IBM Knowledge CenterのDockerの前提条件の節にコンテナのサイズを20GB以上に設定するよう記載されています。これはストレージドライバーとしてdevicemapperを使う場合に該当しますが、本記事で使うoverlay2には関係ありません。

誤ってoverlay2にコンテナサイズのオプションを設定すると、起動時に Job for docker.service failed というエラーが起きてしまいます。

4. Db2 Warehouseコンテナイメージの取得

外部サイトに接続できる環境で作業を行います。

4.1 API keyの取得

  • WebブラウザからIBM Cloudにログインします。（初めてログインする場合は、登録が必要です）

  • 画面が遷移したら、メニューを次のようにたどります。

    • (画面上部)管理 → アクセス(IAM) dashboard.jpg
    • (画面左側)APIキー → (画面中央または右)IBM Cloud APIキーの作成 APIkey.jpg

  • 「APIキーの作成」ポップアップにて名前を入力します。任意に決めて作成ボタンを押します。

  • 「APIキーは正常に作成されました」というポップアップにて、ダウンロードボタンを押します。これで次のjsonファイルが保存されます。

IBM_Cloud_apikey.json
{
    "name": "My API Key",
    "description": "",
    "createdAt": "2020-08-18T07:15+0000",
    "apikey": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}

ファイルのダウンロードは一回しかできないため、このファイルを無くさないようにしましょう。

4.2 コンテナイメージの取得

jsonフィアルに記載されたapikeyを使ってリポジトリ(icr.io)にログインします。続けてイメージ(tarファイル)を取得します。

他環境> echo 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' | docker login -u iamapikey --password-stdin icr.io
Login Succeeded

他環境> docker pull icr.io/obs/hdm/db2wh_ee:v11.5.4.0-CN1-db2wh-linux
v11.5.4.0-CN1-db2wh-linux: Pulling from obs/hdm/db2wh_ee
（中略）
72fcd71969c7: Pull complete
Digest: sha256:3e5d5fdda691423f99002354e0e402141afd288faa35dfabbd5b672d8ba9edb6
Status: Downloaded newer image for icr.io/obs/hdm/db2wh_ee:v11.5.4.0-CN1-db2wh-linux
icr.io/obs/hdm/db2wh_ee:v11.5.4.0-CN1-db2wh-linux

他環境> ls db2wh_ee_v11.5.4.0-CN1-db2wh-linux.tar
db2wh_ee_v11.5.4.0-CN1-db2wh-linux.tar

このtarファイルを導入対象サーバーにアップロードします。

5. Db2 Warehouseコンテナのデプロイ

アップロードしたイメージ（tarファイル）をロードして、実行します。

[root@rhel1 ~]# docker load -i db2wh_ee_v11.5.4.0-CN1-db2wh-linux.tar
（中略）
a2715dab441f: Loading layer [==================================================>]  2.403MB/2.403MB
Loaded image: icr.io/obs/hdm/db2wh_ee:v11.5.4.0-CN1-db2wh-linux

[root@rhel1 ~]# docker run -d -it --privileged=true --net=host --name=Db2wh \
> -v /mnt/clusterfs:/mnt/bludata0 \
> -v /mnt/clusterfs:/mnt/blumeta0 \
> icr.io/obs/hdm/db2wh_ee:v11.5.4.0-CN1-db2wh-linux
0202f667b2c1d0bee1a16e0b147a2f111b6bd62219cac3dcc5a33bdbed3f7ce9

[root@rhel1 ~]# docker logs --follow Db2wh
（中略）
[1413868.371530] start_dashDB_local.sh[53]: #######################################################################
[1413868.375173] start_dashDB_local.sh[53]: ##      --- IBM Db2 Warehouse stack service status summary ---       ##
[1413868.378570] start_dashDB_local.sh[53]: #######################################################################
[1413869.708538] start_dashDB_local.sh[53]: Redirecting to /bin/systemctl status slapd.service
[1413870.883553] start_dashDB_local.sh[53]: SUMMARY
[1413870.883844] start_dashDB_local.sh[53]: Db2TablesOnline               : RUNNING
[1413870.884089] start_dashDB_local.sh[53]: Db2connectivity               : RUNNING
[1413870.884297] start_dashDB_local.sh[53]: Db2running                    : RUNNING
[1413870.884500] start_dashDB_local.sh[53]: LDAPrunning                   : RUNNING
[1413870.884702] start_dashDB_local.sh[53]: WebConsole                    : RUNNING
[1413871.148081] start_dashDB_local.sh[53]: Backing-up the system configuration ...
[1413871.154997] start_dashDB_local.sh[53]: System configuration backed-up to /mnt/blumeta0/SystemConfig/rhel1 on the named volume successfully
[1413933.055046] start_dashDB_local.sh[53]: ********************************************************************************
[1413933.058728] start_dashDB_local.sh[53]: ******                          Congratulations!                          ******
[1413933.062200] start_dashDB_local.sh[53]: ******     You have successfully deployed IBM Db2 Warehouse      ******
[1413933.066090] start_dashDB_local.sh[53]: ********************************************************************************
[1413933.069504] start_dashDB_local.sh[53]: *
[1413933.072765] start_dashDB_local.sh[53]: * Next steps:
[1413933.076029] start_dashDB_local.sh[53]: *
[1413933.079279] start_dashDB_local.sh[53]: * 1. If you were monitoring the container startup progress using docker logs
[1413933.082855] start_dashDB_local.sh[53]: command, use Ctrl+c key-sequence to detach from the Docker logs console.
[1413933.086341] start_dashDB_local.sh[53]: * 3. Log in to the web console using the following information:
[1413933.089672] start_dashDB_local.sh[53]: *        URL: https://xxx.xxx.xxx.xxx:8443
[1413933.093034] start_dashDB_local.sh[53]: *        Default user ID    : bluadmin
*        Default password   : xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
（中略）
[1413934.501874] start_dashDB_local.sh[53]: * 4. For improved security, change the default bluadmin password
[1413934.505954] start_dashDB_local.sh[53]: *        by running "docker exec -it Db2wh setpass <new password>".
[1413934.509524] start_dashDB_local.sh[53]: *        For other user management, use the web console.
[1413934.595884] start_dashDB_local.sh[53]: * Note: Db2wh is an example of a container name. Use the container name
[1413934.596237] start_dashDB_local.sh[53]: that you specified for the docker run command.
[1413934.599805] start_dashDB_local.sh[53]: *
[1413934.603363] start_dashDB_local.sh[53]: ********************************************************************************
（以下略）

実際には上のログの中程に表示された5個のRUNNINGの文字が緑色になっていて、正しく動作していることがわかりやすく表示されます。

bluadminのパスワードを変更します。すぐに変更しない場合は上の画面に表示されたbluadminのパスワードをメモして、コンテナやWeb Consoleにログインするときに取り出せるようにします。

[root@rhel1 ~]# docker exec -it Db2wh setpass xxxxxxxx
Password successfully updated.

導入後の使い方については参考資料として挙げたQiita記事をご覧下さい。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-17T14:58:34+09:00

Dockerの容量について

概要

Docker学習のアウトプットとして、まとめます。
今回はDockerの容量についてです。

容量に注意

Dockerを使用しているとPCのハードディスクの容量を何十ギガと使用してしまうことがあります。
イメージやコンテナを削除してもDockerが削除したはずの容量を掴みっぱなしで容量が空かないことがあります。

対処方法

下記手順で容量を空けることができます。
ターミナルにて

docker system prune

yes/noを聞かれるので、yesと入力しEnterキーを入力
ゴミ掃除をするためのコマンドなにります。

次に
Docker for Macアプリケーションの
Preference>Reset>Reset to factory defaults
を選択し、再起動を行う。

以上で完了。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-17T00:52:36+09:00

rails チュートリアル

6章まで終了
次回7章から

mailの大文字小文字問題が消化不良

データベースのindexについてあとで調べる必要あり

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-17T00:49:15+09:00

WSL2 + Docker Desktop + VSCode（Remote - Containers） でGoの開発環境構築

概要

バージョン2004で正式導入されたWSL2ですが、先日バージョン1909と1903へのバックポートが発表されました！
https://devblogs.microsoft.com/commandline/wsl-2-support-is-coming-to-windows-10-versions-1903-and-1909/
筆者の開発PCは2004へのアップデートが許可されていないので、非常に助かります。
そこで今回は、Docker Desktop for WindowsのWSL2インテグレーション機能と、VSCodeのRemote - Containers拡張機能を使って、Dockerfileでコンテナ内にGoの「快適な」開発環境を作ってみるところまでやってみようと思います。
※既に以下のような素晴らしい記事があり書くのを迷いましたが、自身の理解を深めるのと備忘録も兼ねて書きました。
https://tech-lab.sios.jp/archives/21675

筆者の環境

エディション バージョン OSビルド
Windows 10 Pro 1909 18363.1049

システム要件

エディション バージョン OSビルド
Windows 10（全エディション） 2004 -
Windows 10 x64（全エディション） 1909 18363.1049 以上
Windows 10 x64（全エディション） 1903 18362.1049 以上

手順

  1. WSLをインストールし、WSL2に更新する

  2. Docker Desktop for Windows をインストールする

  3. VSCoceの拡張機能 Remote Containers を使って、Goの開発環境を構築する

1. WSLをインストールし、WSL2に更新する

以下URLの公式手順通りにやれば問題ありませんが、一応この記事でも手順を書いておきます。
https://docs.microsoft.com/ja-jp/windows/wsl/install-win10

1‐1. CPU仮想化が有効になっているか確認

タスクマネージャを開き、CPUの仮想化が有効となっていることを確認してください。
もし有効になっていない場合は、BIOS（UEFI）で仮想化を有効にしてください。（メーカーによって設定方法が異なるので説明は割愛します）
image.png

1‐2. Windows Subsystem for Linuxをインストールする

GUI（マウス操作）でやる場合

コントロールパネル > プログラムと機能 > Windowsの機能の有効化または無効化の順に選択して以下画面を開き、Linux用Windowsサブシステムにチェックを入れます。
image.png

CUI（コマンド操作）でやる場合

管理者権限でPowerShellを開き、以下コマンドを実行してください。

powershell
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

成功すると以下のようなメッセージが表示されます。

powershell
展開イメージのサービスと管理ツール
バージョン: 10.0.18362.900

イメージのバージョン: 10.0.18363.1049

機能を有効にしています
[==========================100.0%==========================]
操作は正常に完了しました。

1‐3. 仮想化マシンプラットフォームのオプションコンポーネントを有効にする

GUI（マウス操作）でやる場合

先程と同様に、コントロールパネル > プログラムと機能 > Windowsの機能の有効化または無効化の順に選択して以下画面を開き、仮想マシンプラットフォームにチェックを入れます。
image.png

CUI（コマンド操作）でやる場合

管理者権限でPowerShellを開き、以下コマンドを実行してください。

powershell
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

成功すると以下のようなメッセージが表示されます。

powershell
展開イメージのサービスと管理ツール
バージョン: 10.0.18362.900

イメージのバージョン: 10.0.18363.1049

機能を有効にしています
[==========================100.0%==========================]
操作は正常に完了しました。

1‐4. PCを再起動する

PCを再起動してWSLのインストールとWSL2の更新を完了させます。

1‐5. WSL2を既定のバージョンとして設定する

新しいLinuxディストリビューションをインストールする際の既定のバージョンをWSL2に変更します。
PowerShellを開き、以下コマンドを実行してください。

powershell
wsl --set-default-version 2

以下のメッセージが表示された場合はLinuxカーネルを更新する必要があります。

powershell
WSL 2 を実行するには、カーネル コンポーネントの更新が必要です。詳細については https://aka.ms/wsl2kernel を参照してください
WSL 2 との主な違いについては、https://aka.ms/wsl2 を参照してください

メッセージに表示されている以下URLにアクセスし、Linuxカーネル更新プログラムパッケージをダウンロードします。
https://aka.ms/wsl2kernel

ダウンロードしたインストーラーを起動し、Nextをクリックすればインストール完了です。
image.png

インストールが完了したら、再び以下コマンドを実行してみてください。今度は成功するはずです。

powershell
wsl --set-default-version 2

1‐6. Linuxディストリビューションのインストール

Microsoft Storeを開き、Linuxディストリビューションをインストールします。
wslで検索すればいくつか候補が出てきます。
image.png

何でもいいですが、今回はUbuntuをインストールします。
image.png

インストールが完了したら、Ubuntuを起動します。
しばらく待つとユーザー名とパスワードの入力を促されるので、任意のものを入力します。
※今後Ubuntu内で何かするときはパスワード入力を求められるので、パスワードは忘れないでください。
image.png

これで、Windows上でLinux（Ubuntu）を起動できるようになりました！
image.png

念のためPowerShellを開き、以下コマンドを実行してWSLのバージョンが2になっていることを確認しましょう。

powershell
wsl -l -v
  NAME      STATE           VERSION
* Ubuntu    Running         2

2. Docker Desktop for Windows をインストールする

次に、Docker Desktop for Windowsをインストールし、Dockerを使えるようにします。

ここで注意点ですが、以下のリリースノートに記載してある通り、バージョンが1909 1903の場合はDocker Desktop Community 2.3.5.0 以上をインストールする必要があります。
https://docs.docker.com/docker-for-windows/edge-release-notes/

執筆時点（2020年9月4日）では、Stable版（安定板）の最新バージョンはDocker Desktop Community 2.3.0.4です。
筆者の環境はバージョン1909なので、今回はEdge版をインストールします。
バージョン2004の方はStable版でも問題ないと思います。

以下URLにアクセスし、Docker Desktop for WindowsのEdge版のインストーラーをダウンロードします。
https://hub.docker.com/editions/community/docker-ce-desktop-windows/

インストーラーを起動すると、最初にConfiguration画面が立ち上がります。
今回はDockerのバックエンドをWSL2にしたいので、Install required Windows components for WSL2にチェックが入っていることを確認します。
従来のHyper-V型は使わないので、Enabled Hyper-V Windows Featuresはオフにしておきます。
image.png

OKボタンをクリックするとインストールが始まります。以下画面が表示されたら成功です。
Close and log outボタンをクリックするとログアウトされるので、再度Windowsにログインします。
image.png

ログイン後、Docker Desktop for Windowsが自動的に起動します。
しばらく待って起動に成功すると以下画面が表示されます。
Startボタンをクリックするとチュートリアルが始まりますが、今回はSKIPします。
image.png

画面上部の歯車アイコンをクリックして、Generalの設定でUse the WSL2 backend engineがチェックされていることを確認します。
image.png

dockerコマンドが使用できるかどうか確認します。
PowerShellを起動してdocker versionコマンドを実行し、バージョンが表示されるかどうか確認します。
image.png

同じくUbuntuを起動してdocker versionコマンドを実行し、バージョンが表示されるかどうか確認します。
image.png
これで、WindowsでDockerが使用できるようになりました！

3. VSCoceの拡張機能 Remote-Containers を使って、Goの開発環境を構築する

最後に、Dockerコンテナ内でGoの開発を「快適に」行うための準備をしていきます。

Dockerコンテナで開発する際のメリットとしては以下のようなものがあります。

  • 開発に必要な手順が記載されているDockerfileがあれば、コンテナを起動するだけですぐに開発できる環境が整います。
  • チーム内にDockerfileを配布すれば、チーム全員が同じ環境で開発することができます。
  • ランタイムやツールのインストールなどをする必要がないので、ホスト環境を汚しません。

Remote-Containersを使えば、上記のメリットに加えて、VSCodeで開発作業が行えるようになるので、コードの編集はもちろん、インテリセンス、構文チェック、定義ジャンプ、デバッグなどの豊富な支援機能も使えるようになり、コンテナ内での開発が非常にスムーズになります。

それでは早速やっていきましょう。

3-1. VSCoceの拡張機能 Remote Developmentのインストール

まず、VSCodeの拡張機能に、Remote Developmentをインストールします。
こちらはRemote-WSLとRemote-ContainersとRemote-SSHのセットになっています。
image.png

3-2. VSCodeをWSL(Ubunt)から起動する

次に、Ubuntuを起動します。
mkdirでgo-sampleフォルダを作成し、cdで作成したフォルダに移動してから、code .コマンドでVSCodeを起動します。
image.png

すると、VSCodeがWSL（Ubuntu）のgo-sampleフォルダを開いた状態になります。
image.png

3-3. Dockerfileの作成

次に、go-sample直下に.devcontainerというフォルダを作成します。
.devcontainerフォルダ内に、Dockerfileという名前のファイルを作成します。
内容は以下の通りにします。

goのバージョンは1.13.15にしてますが、1.14系やlatestでも問題ないです。
go getでインストールしているのはGo開発で必要なツール群です。
※コンテナをリビルドする度にインストールするのが面倒だったので、Dockerfile内に書きました。もっと良いやり方があったら教えてください！

Dockerfile
FROM golang:1.13.15

RUN go get -v -u \
    github.com/mdempsky/gocode \
    github.com/uudashr/gopkgs/v2/cmd/gopkgs \
    github.com/ramya-rao-a/go-outline \
    github.com/acroca/go-symbols \
    golang.org/x/tools/cmd/guru  \
    golang.org/x/tools/cmd/gorename \
    github.com/cweill/gotests/... \
    github.com/fatih/gomodifytags \
    github.com/josharian/impl \
    github.com/davidrjenni/reftools/cmd/fillstruct \
    github.com/haya14busa/goplay/cmd/goplay \
    github.com/godoctor/godoctor \
    github.com/go-delve/delve/cmd/dlv \
    github.com/stamblerre/gocode \
    github.com/rogpeppe/godef \
    golang.org/x/tools/cmd/goimports \
    golang.org/x/lint/golint \
    golang.org/x/tools/gopls

3-4. devcontainer.jsonの作成

同じく.devcontainerフォルダ内にdevcontainer.jsonという名前のファイルを作成します。
内容は以下の通りにします。

settingsで設定、extentionsで拡張機能を指定できるので、お好みでどうぞ。
今回はGoの拡張機能をインストールして、設定をちょっと変えています。
エディタの環境まで共有できるのですごく便利ですね！

devcontainer.json
{
    // VSCodeに表示されるワークスペース名
    "name": "go-sample",

    // Docker buildを実行するディレクトリ。devcontainer.jsonファイルからの相対パスで設定します。
    "context": "..",

    // コンテナの内容を定義するDockerfileのパス。devcontainer.jsonファイルからの相対パスで設定します。
    "dockerFile": "Dockerfile",

    // コンテナ側のVSCodeの設定値（setting.json）を変更したい場合、設定します。
    "settings": {
        "terminal.integrated.shell.linux": "/bin/bash",
        "go.formatTool": "goimports",
        "go.useLanguageServer": true,
    },

    // コンテナ側のVSCodeに拡張機能をインストールする必要がある場合、拡張機能のIDを配列で設定します。
    "extensions": [
        "golang.Go"
    ]
}

3-5. Remote-Containersでコンテナにリモート接続する

次に、左下にある>< WSL: Ubuntuをクリックし、Remote-Containers: Reopen in Containerを選択します。
image.png

VSCodeが再読込され、コンテナ内で起動します。
先程WSL(Ubuntu)側で作成したフォルダ／ファイルがマウントされているのがわかります。
※初回はコンテナの作成に時間がかかりますが、次回からはもう少し早く起動すると思います。
image.png

ターミナルでBashを起動し、go versionを実行します。
Goのバージョン1.13.15がインストールされていることを確認できます。
image.png

左下の歯車アイコンから設定を開き、@modifiedと入力して変更した設定のみを表示します。
devcontainer.jsonのsettingsで記載した内容が、リモート側のVSCode設定に反映されていることを確認できます。
image.png

拡張機能はローカルにインストールするものとリモート側にインストールするものとで管理が分かれます。
devcontainer.jsonのextensionsで設定したGoの拡張機能がリモート側にインストールされていることを確認できます。
image.png

Dockerfileでインストールするよう設定したGoのツール群もインストールされています。
image.png

Docker Desktopでもイメージが作成されていることが確認できます。
image.png

コンテナも作成され、起動中（RUNING）になっています。
image.png

3-6. コンテナ内でのGo開発（hello world）

環境が整ったので、コンテナ内でGoのhello worldを作ってみます。
ワークスペース直下にmain.goという名前のファイルを作成します。
内容は以下の通りにします。

コピペでなく自分で入力すると、インテリセンスやスニペットなどの支援機能が効いていることが実感できると思います。

main.go
package main

import "fmt"

func main() {
    fmt.Println("hello world")
}

ターミナルでBashを開き、go run main.goを実行します。hello worldと出力されれば成功です！
image.png

デバッグもやってみます。
main.goのソース上でfmt.Println("hellow world")にブレイクポイントを設定し、F5キーを押します。
image.png

しばらくするとデバッグが実行され、設定したブレイクポイントで止まります。
image.png

デバッグツールバーのステップオーバーをクリックするか、F10キーを押すと次のステップへ進みます。
fmt.Plintlnが実行されて、デバッグコンソールにhello worldを出力されることが確認できます。
image.png

これでGoのデバッグが出来るようになりました！
※デバッグを終了させる場合は再度F5キーを押してください。

3-7. コンテナへのリモート接続を終了する

コンテナへのリモート接続を終了させる場合は、左下の>< Dev Containerからリモート接続を終了するを選択するか、右上の×ボタンでVSCodeを閉じてください。
image.png

3-8. コンテナへのリモート接続を再開する

再度コンテナへのリモート接続をする場合は、WSL(Ubunt)でgo-sampleフォルダを開き、左下の>< WSL: UbuntuからRemote-Containers: Reopen in Containerを選択してください。
image.png

初回起動では32.373秒かかりましたが、2回目は18.217秒で起動できました。
image.png

3-9. （おまけ）Windowsから直接Remote-Containersでコンテナにリモート接続する

今回はWSL(Ubuntu)内にソースコードを配置して、WSL(Ubuntu)からVSCodeのRemote-Containersでコンテナを起動しましたが、Windows上にソースコードを配置して、Windowsからコンテナを起動することもできます。

やり方はWSL(Ubuntu)の時と同じで、3-3～3-5の手順をWindows上で行うだけです。
ソースコードはWindowsで管理したいよ！っていう方はその方法でも良いかもです。
image.png

初回起動では39.594秒かかりました。WSL（32.373秒）より若干遅い？です。
image.png

注意点としては、Windowsからコンテナを起動すると、Docker Desktopが以下の警告を表示します。
image.png

Docker Desktopは、WindowsファイルをWSL2コンテナーに共有したことを検出しました。これはパフォーマンスが低下する可能性があります。

https://docs.docker.com/docker-for-windows/wsl/#best-practices
上記URLのDocker Desktop WSL2 Backendのベストプラクティスにもあるように、Linuxファイルシステムからマウントされるとパフォーマンスが大幅に向上するようです。Windowsファイルシステムからコンテナを起動するのは避けるように、ともあるので、気になる方はWSLでソースコードを管理したほうがよさそうです。

まとめ

WSL2とDocker Desktop for WindowsとVSCodeの相性が良く、WindowsでもDocker開発がスムーズに行えるようになってきました。
Dockerfileで開発環境を共有できるのはもちろんですが、devcontainer.jsonでVSCodeの設定や拡張機能まで共有できるのもいいですね！
※Goはまだいいですが、ReactやVueなどのフロントエンドの開発だとESLintとPrettierの設定などでかなり労力を持っていかれるので、、、
これからは開発で積極的に取り入れていきたいと思います！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-17T00:03:32+09:00

(自分用)自宅用にubuntu18.04+dockerでgitlabを構築する(備忘録)

はじめに

こんばんは
色々やりたい事や勉強したいことがありながらも
ニコ生みたり雀魂とかapexやってしまい思うように時間がとれていない今日この頃です。

svnくらいしか使ってこなかった私の職場もそろそろgitを使おうかという流れが
でてきたので勉強がてら自宅にgitlabを構築しようと思います。

Ubuntu18.04の構築

まずはgitlabを構築する環境を作ります。
今回はesxi上にubuntu18.04を作りたいと思います。

  1. 作成タイプの選択
    image.png
    今回は新規仮想マシンを選びます。

  2. 名前とゲストOSの選択
    image.png

  3. ストレージの選択
    image.png

  4. 設定のカスタマイズ
    image.png
    設定はこんな感じにしました。
    特別なことはないですが注意したいのはCD/DVDメディアでISOファイルの設定を忘れないことですかね。
    これをやっておかないとubuntuのインストールができません。

  5. 完了
    次へと完了を押してイメージを作成します。

Ubuntuのインストール

  1. 起動
    image.png
    まずは起動します。

  2. Ubuntuをインストールを選択
    image.png

  3. キーボードレイアウト
    image.png

  4. アップデートと他のソフトウェア
    image.png

  5. インストールの種類
    image.png

  6. どこに住んでいますか？
    image.png
    俺は東京生まれHIP HOP育ち 悪そうな奴は大体フレンズ

  7. あなたの情報を入力してください
    image.png

  8. インストール
    image.png
    インストールが終わるまでしばし待ちます。

  9. 再起動
    image.png
    再起動します。

docker, docker-compose

再起動が出来たらまずはdocker, docker-compoeをインストールしていきます。

  1. docker

基本的にはdocker公式の通りにdockerをインストールしていきます。

sudo apt-get remove docker docker-engine docker.io containerd runc

# Update the apt package index and install packages to allow apt to use a repository over HTTPS:
sudo apt-get update
sudo apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common

# Add Docker’s official GPG key:
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

# Use the following command to set up the stable repository. To add the nightly or test repository, add the word nightly or test (or both) after the word stable in the commands below. Learn about nightly and test channels.
sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"

sudo apt-get update

# docker install
sudo apt-get install docker-ce docker-ce-cli containerd.io

ルート権限がなくてもdockerを実行できるように設定します。

sudo groupadd docker

sudo usermod -aG docker $USER

# ログアウトすれば反映されるらしいですが私の環境だと反映されなかったので
# ここで一度再起動します。
sudo reboot

# 再起動後、dockerが表示されていればOKです
groups

image.png

# docker-ceのversionを指定してinstallする場合はこちら
# List the versions available in your repo:
apt-cache madison docker-ce

# 例
sudo apt-get install docker-ce=5:19.03.12~3-0~ubuntu-bionic docker-ce-cli=5:19.03.12~3-0~ubuntu-bionic containerd.io

テストしてみます

# Verify that Docker Engine is installed correctly by running the hello-world image.
sudo docker run hello-world

# イメージがあるか確認します
docker ps -a

image.png
大丈夫そうです

2.　docker-compose

sudo apt install docker-compose

# インストールの確認
docker-compose -v
# ↓が表示されていればOK(versionは適宜読み替えください)
docker-compose version 1.17.1 build unknown

image.png

gitlab

ようやっとgitlabの構築です。
gitlab公式をみていきます。

公式のdocker-compose.ymlを真似るのでまずは環境変数を定義します

# 先にフォルダを作成します
sudo mkdir -p /srv/gitlab
# 環境変数
export GITLAB_HOME="/srv/gitlab"

※これをしておかないと次のdocker-compose.ymlだとコンテナが正しく上がってきません
docker-compose.yml配下のフォルダをvolumeで指定してもいいと思いますがそれだと何故かコンテナがうまく立ち上がってこないので公式と同じにしました。
(権限かなにかがよろしくない？)

# 適当にフォルダを作ります
mkdir gitlab && cd gitlab

# docker-compose.ymlを作ります
touch docker-compose.yml

# editorで開いて中身を書きます
gedit docker-compose.tml
docker-compose.yml
web:
  image: 'gitlab/gitlab-ce:latest'
  hostname: '自PCのIPアドレス'
  restart: always
  environment:
    GITLAB_OMNIBUS_CONFIG: |
      external_url 'http://自PCのIPアドレス:80/gitlab/'
      gitlab_rails['time_zone'] = 'Asia/Tokyo'
  ports:
    - '80:80'
    - '443:443'
    - '22:22'
  volumes:
    - '$GITLAB_HOME/config:/etc/gitlab'
    - '$GITLAB_HOME/logs:/var/log/gitlab'
    - '$GITLAB_HOME/data:/var/opt/gitlab'

docker-compose.ymlはこんな感じにしました。
設定項目は他にもあるみたいなので必要になったら追記しましょう。
また、運用を考える際はgitlabのversionを固定したほうがいいですかね。
また、portはもし既に利用中のものがある場合は適当な数字に置き換えましょう。

# gitlabの起動
docker-compose up -d

起動にけっこう時間がかかります。
気長に待ちましょう。

起動ができたらブラウザを開いてexternal_urlで指定したURLを叩いてみましょう。
下の画面が表示されればOKです。
あとは管理者PWを変更し、Registerからユーザーの登録を行いましょう。
例：http://自PCのIPアドレス:80/gitlab/
image.png

終わりに

これでubuntu18.04にdocker,docker-composeを用いてgitlab環境を構築することができました。
会社で構築する時はubuntuやdockerにproxyの設定が必要になるかもしれませんが自宅ならこんな感じでOKです。
こんなに簡単に自宅にgitlabを構築できるとは有り難いですねぇ。
ちなみにオンプレでgitlabをubuntuに直接インストールするとなぜかgitlabの設定更新で止まってしまいうまくいきませんでした。
まあ、docker使った方が簡単にできそうなのでヨシ!とします。

参考URL

https://docs.docker.com/engine/install/ubuntu/
https://docs.gitlab.com/omnibus/docker/
https://qiita.com/soumi/items/baaa35b37f6c90a66c0c
http://imamachi-n.hatenablog.com/entry/2018/04/29/193718
https://demura.net/deeplearning/16931.html

上記URLに感謝します。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧