dockerによるCIと、コンテナクラスタリング構築の記録を残していきます。

スマートフォンベースのECサイトのプロジェクトへ配属になりました。
プロジェクトはオーソドックスなLAMP構成＋jQueryによるインタラクションが付与されたものですが、中〜大規模のPVを持っており、決済機能も存在する事から
品質管理やリリース手順などは整備されていました。

ライフサイクルとしては成熟期を過ぎた印象があり、プロダクトとしては一定の完成度に達していたので
バックエンドより、ユーザが直接関わるUI部分の改修に比重が置かれ
インフラ部分については、現状動いているのだから、コストを掛けて改修するほど優先度は高くない、といった状況でした。

そんな中で、合間を見てdocker環境を構築し、現場に浸透させて行った記録です。
docker環境の構築の助けになれば幸いです。
（記録になるので、ベストプラクティスから外れている部分も多いかと思いますが、ご容赦下さい）

当時の開発環境

開発環境は、VirtualBox(Vagrant)でCentOSベースのイメージを一つ起動し
一つのOSの内に
・サービス内で展開している、三種類の２層webアプリケーション（VirtuaHostによる統合）
・上記３アプリケーションから参照するmysql
・DB負荷軽減の為のRedisサーバ
が同居しています。

その他、CDNとしてAWS S3を採用している為、擬似S3となるminoサーバを
ホストマシン上で起動しています。
ホストマシン上のGitHubのリポジトリを、Vagrantのイメージにマウントし、エディタで開発を行なっていました。

開発環境の問題点

前述の通りインフラ構築は逆風の雰囲気でしたが
開発チームからは、開発環境の問題の指摘が挙げられていました。

1.Virtualboxの起動速度

Virtualboxは、仮想環境内でOSを起動する為起動にリソースを消費しますが
dockerはホストOSの機能を共有して、docker仮想環境内で
アプリケーションが格納されたコンテナを起動する為、
「OSを起動する」部分のオーバーヘッドが無く、起動が高速になります。
docker導入のメリットとして訴求しました。

2.サービス環境と開発環境で、構成が異なり、健全ではない

■開発環境は、３つの２層webアプリケーションを１つのEC2インスタンスに集約していましたが
商用環境は、AWS EC2を3台に分け（別途、multi-AZも実施している）
それぞれのアプリケーションを分けて配置していました。
■開発環境はCentOS６（何故かOSのメッセージ全般がドイツ語）でしたが、
商用はAmazonLinuxでした。

dockerでコンテナ毎にサーバを構築する事で、商用と同じ３サーバ構成にする事で、解決を試みました。
OS差分の問題は、AmazonLinuxのDockerイメージを使うことも考えましたが
開発陣からの、「商用と同じ環境」をより納得させる為に、
商用で稼働しているAmazonLinuxを、Dockerイメージとして使うことで、心理的安全性を担保する事にしました。

将来的にAWS ECSによる、コンテナクラスタのデプロイを想定し
その際は、alpineで再構築する予定だったので、この対応は繋ぎという形でした。
（正直、そのままalpineで構築しておけばよかった）

3.Githubリポジトリが２つ存在し、連携しにくい

配属以前は、SASS/JS/HTMLが別リポジトリで管理されていました。
フロントのリポジトリで、gulpを使用したhtml+SASS+JSのモックを作成し
バックエンドのリポジトリに（ZIPか何かで）移植、viewファイルへ反映を行なっていましたが
・２つのリポジトリとのバージョン整合が大変
・移植コストが大きい。大規模なフロントエンド開発がもう無さそう
という事を考慮し、リポジトリをバックエンドに統合する事にしました。
統合により
・バックエンドのJSやSASSの変更をgulpで検知しコンパイル、ブラウザに即時（又はリロード）で反映
・PHPソースとJS/CSSが正しくバージョン管理されているので、将来的には継続的デプロイとして、GitHubへのPUSH時、JS・SASSを自動でコンパイルし、dockerimageの自動デプロイと、JSやCSS,画像ファイルのS3への自動反映
(AWS codebuildを想定）
が可能だと見積りました。

プロトタイプ作成

プロトタイプを見せる事が説得力に繋がると感じたので、業務の合間にdockerの構築を進めていくことになりました。

概要

DockerComposeを使ってブランチごとに環境を自動生成する

前提

アプリケーション：JDK1.8, SprngBoot
DB：PostgreSQL11

Docker-Compose

docker-compose.yml

version: "3"

services:
  db:
    image: postgres:11
    ports:
      - 5432:5432
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: root
      POSTGRES_DB: hoge
      POSTGRES_INITDB_ARGS: "--encoding=UTF-8"
    volumes:
      - database:/var/lib/postgresql/data
      - ./initdb:/docker-entrypoint-initdb.d
    restart: always
    user: root

  app:
    build: .
    image: app/hoge:8080
    ports:
      - 8080:8080
    volumes:
      - .:/app
    depends_on:
      - db
    links:
      - db

volumes:
  database:
    driver: local

appのポートはブランチを識別できる番号にしておく。例えばチケット番号など。

Dockerfile

FROM openjdk:8-jdk-alpine
VOLUME /tmp
RUN mkdir /app
WORKDIR /app
ENV JAVA_OPTS=""
ENTRYPOINT java -jar build/libs/hoge.jar --server.port=8080

初期データ

initdbフォルダに下記を入れておく
initdb.sh
/dump/dump.sql

initdb.sh

pg_restore -d hoge -Fc -c /docker-entrypoint-initdb.d/dump/dump.sql

実行

イメージ作成＆コンテナ起動

docker-compose up --build

8080ポートでアクセスしてSpringBootのアプリケーション画面が表示されればOK

最後に

もっとスマートな方法が無いか検討中。
ブランチごとに環境を動的生成している経験者の方のアドバイスを頂きたいです。

あと、SSOを使っていて認証サーバ側でクライアント登録する必要がある場合はしんどい・・・

こちらのサイトを参考に進めています。
https://dev.classmethod.jp/cloud/zabbix-docker-monitoring/

概要

対象のホスト機へ監視用のDockerコンテナを作成し、zabbix_serverで監視することで、その他のDockerコンテナも監視できる。
取得できる値　-> CPU MEM SWAP 死活監視
その他にも未検証ですが、ネットワーク監視用のテンプレートもありました。
https://raw.githubusercontent.com/cavaliercoder/zabbix-module-sockets/master/templates/Template_App_TCP_Sockets_3.2.xml

注意

以下手順では、Dockerimageを「zabbix-agent-xxl」ではなく一つ古い「dockbix-agent-xxl-limited」を使用してます。
（dockbix-agent-xxl-limited はCPUの値が取得できず断念...）

テンプレートの入手 -> インポート

テンプレートURL: https://github.com/monitoringartist/zabbix-docker-monitoring/blob/master/template/Zabbix-Template-App-Docker.xml
リンクのままだと使えないので以下のように編集する
(zabbix2.2ではfilerが使えないようです。ここでだいぶハマりました...)

52行目の「filter」をコメントアウト
<!--               <filter>
                        <evaltype>0</evaltype>
                        <formula/>
                        <conditions/
                    </filter>
 -->

■zabbix-server へテンプレートをインポート

設定 -> テンプレート -> インポート -> ファイルを選択 しインポート

dockerコンテナの作成

docker監視対象へモニタリング用のdockerコンテナを起動させる。
（portは適宜使用していないportを使用。下記では、ホスト機もzabbix-agentを入れているので、10150使用。）
には監視元serverのIPを入力

docker pull monitoringartist/dockbix-agent-xxl-limited
docker run \
  --name=dockbix-agent-xxl-limited \
  -h docker-host-1 \
  -p 10150:10050 \
  -v /:/rootfs \
  -e "ZA_Server=<ZABBIX SERVER IP/DNS NAME>" \
  -d monitoringartist/dockbix-agent-xxl-limited:latest

zabbix管理画面で新たにホストの追加

- ホスト名はわかりやすいように {$HOSTNAME}_docker_monitoring など
- 設定 -> ホスト -> ホストの作成
ホスト名: example_docker_monitoring
グループ: 適宜
IP: ホストのIP
ポート: 10150
テンプレート: Templates -> Template App Docker - www.monitoringartist.com
しばらくすると値が取得できます。

監視サーバーから以下コマンド実行すると値が取得できているかわかります。

zabbix_get -s  <監視対象IP> -k docker.discovery -p 10150

参考

https://dev.classmethod.jp/cloud/zabbix-docker-monitoring/
https://github.com/anapsix/zabbix-haproxy/issues/1
https://github.com/anapsix/zabbix-haproxy/pull/2
https://hub.docker.com/r/monitoringartist/dockbix-agent-xxl-limited/

こちらのサイトを参考に進めています。
https://dev.classmethod.jp/cloud/zabbix-docker-monitoring/

概要

対象のホスト機へ監視用のDockerコンテナを作成し、zabbix_serverで監視することで、その他のDockerコンテナも監視できる。
取得できる値　-> CPU MEM SWAP 死活監視
その他にも未検証ですが、ネットワーク監視用のテンプレートもありました。
https://raw.githubusercontent.com/cavaliercoder/zabbix-module-sockets/master/templates/Template_App_TCP_Sockets_3.2.xml

注意

以下手順では、Dockerimageを「zabbix-agent-xxl」ではなく一つ古い「dockbix-agent-xxl-limited」を使用してます。
（dockbix-agent-xxl-limited はCPUの値が取得できず断念...）

テンプレートの入手 -> インポート

テンプレートURL: https://github.com/monitoringartist/zabbix-docker-monitoring/blob/master/template/Zabbix-Template-App-Docker.xml
リンクのままだと使えないので以下のように編集する
(zabbix2.2ではfilerが使えないようです。ここでだいぶハマりました...)

52行目の「filter」をコメントアウト
<!--               <filter>
                        <evaltype>0</evaltype>
                        <formula/>
                        <conditions/
                    </filter>
 -->

■zabbix-server へテンプレートをインポート

設定 -> テンプレート -> インポート -> ファイルを選択 しインポート

dockerコンテナの作成

docker監視対象へモニタリング用のdockerコンテナを起動させる。
（portは適宜使用していないportを使用。下記では、ホスト機もzabbix-agentを入れているので、10150使用。）
には監視元serverのIPを入力

docker pull monitoringartist/dockbix-agent-xxl-limited
docker run \
  --name=dockbix-agent-xxl-limited \
  -h docker-host-1 \
  -p 10150:10050 \
  -v /:/rootfs \
  -e "ZA_Server=<ZABBIX SERVER IP/DNS NAME>" \
  -d monitoringartist/dockbix-agent-xxl-limited:latest

zabbix管理画面で新たにホストの追加

- ホスト名はわかりやすいように {$HOSTNAME}_docker_monitoring など
- 設定 -> ホスト -> ホストの作成
ホスト名: example_docker_monitoring
グループ: 適宜
IP: ホストのIP
ポート: 10150
テンプレート: Templates -> Template App Docker - www.monitoringartist.com
しばらくすると値が取得できます。

監視サーバーから以下コマンド実行すると値が取得できているかわかります。

zabbix_get -s  <監視対象IP> -k docker.discovery -p 10150

追伸 (トリガーの設定,不具合など)

トリガー設定
■5分間値が取得できなかったら (dockbix-agent-xxlが停止したことを想定)
Container {#HCONTAINERID} is not running
条件式: {Template App Docker - www.monitoringartist.com:docker.up[/{#HCONTAINERID}].nodata(5m)}=1

■5回連続でdocker.upが0の値(Exited 状態の場合)
Container {#HCONTAINERID} is not running
条件式: {Template App Docker -www.monitoringartist.com:docker.up[/{#HCONTAINERID}].count(#5,0,"eq")}=5

■dockbix-agent-xxlを一度停止すると起動できなくなるので（謎ですが）
再度作成し直す。

docker stop dockbix-agent-xxl
docker rm dockbix-agent-xxl
docker run \
  --name=dockbix-agent-xxl \
  -h docker-host-1 \
  -p 10150:10050 \
  -v /:/rootfs \
  -e "ZA_Server=<ZABBIX SERVER IP/DNS NAME>" \
  -d monitoringartist/dockbix-agent-xxl-limited:latest

参考

https://dev.classmethod.jp/cloud/zabbix-docker-monitoring/
https://github.com/anapsix/zabbix-haproxy/issues/1
https://github.com/anapsix/zabbix-haproxy/pull/2
https://hub.docker.com/r/monitoringartist/dockbix-agent-xxl-limited/

前提

• ECSでRailsアプリが起動されていること
• migrateはfargateでやってなかった
• テスト環境でやること

作業内容

https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/userguide/ecs_run_task_fargate.html
これ見ながら作業する。実際は、コマンドでやると何をしているのかよくわからないので、まずはGUIでやる。把握した後にコード化するというのが良い。そうすることで、全てのオプションやらパラメータの世界が見えてくる。

念の為、新規DBを作成

t2.microなどで良い
何らかのエラーが出たときの切り分けにしたい。
インスタンスが作れたら、アプリケーションデプロイ用のタスクにDBの環境変数を設定する（System Managerが使えるなら ECS containerから valueFrom で呼び出せるのでjson自体をgit管理できる。AWSでマネージドされているのが良い）

taskを定義する

実際は、コマンドなどを付与したりするのでENTRYPOINTで設定している。
これは、Initial,Migrate,Seedそれぞれリビジョンで分けるだけで良い。Initial,Seed,Migrateの順で作る。
※なお、実際の運用ではInitialやらSeedは使わない。これは、今回新規でRDSを立ち上げたので必要になっただけ。LATESTリビジョンだけがあれば良い。

key	value
ネットワークモード	awsvpc
互換性が必要	FARGATE
タスクメモリ(GB)	0.5GB
タスクCPU(vCPU)	0.25 vCPU

containerの環境設定(Initial)

key	value
エントリポイント	bundle,exec,rails,db:create
作業ディレクトリ	/app(アプリがある場所）

  "containerDefinitions": [
    {
      "entryPoint": [
        "bundle",
        "exec",
        "rails",
        "db:create"
      ],
      "workingDirectory": "/app"
    }
  ]

containerの環境設定(Migrate)

key	value
エントリポイント	bundle,exec,rails,db:migrate
作業ディレクトリ	/app(アプリがある場所）

  "containerDefinitions": [
    {
      "entryPoint": [
        "bundle",
        "exec",
        "rails",
        "db:migrate"
      ],
      "workingDirectory": "/app"
    }
  ]

containerの環境設定(Seed)

key	value
エントリポイント	bundle,exec,rails,db:seed,a=b
作業ディレクトリ	/app(アプリがある場所）

  "containerDefinitions": [
    {
      "entryPoint": [
        "bundle",
        "exec",
        "rails",
        "db:seed",
        "a=b"
      ],
      "workingDirectory": "/app"
    }
  ]

taskを実行する

• VPCを設定、subnetを設定
• ネットに繋がるものを設定しておく

２つエラーが発生した

• メモリ不足エラー　→　メトリクスをチェックして、スペックの問題ならスペックを上げる
  • コンテナインスタンスのリソースから、メモリ使用量を見る
• ECRからイメージをpullしてこれず、エラー　→　インターネットにつながるネットワークを設定する

結果を見る

• PROVISIONING→PENDING→RUNNING→STOPのようなフローだったような気がする
• タスクのStoppedの中でログを確認する。
• Migrateタスクならば、以下のようなログが吐かれているだろう。

2019-10-09 18:16:45D, [2019-10-09T09:16:45.290941 #1] DEBUG -- : [1m[35m (572.8ms)[0m [1m[35mCREATE DATABASE "test_database" ENCODING = 'unicode'[0m
2019-10-09 18:16:45Created database 'test_database'

• 実際にアプリケーション側でも確認する。
• 問題がなければCodeDeployやCIなどで連携する。

内容

• ssh-agentを使ってサーバー上でGithubにssh接続する
• DockerのBuild-time secretsとssh-keyscanを使ってbuild時にGithubにssh接続する

具体例としてDockerのbuild中にプライベートレポジトリにあるパッケージを pip install する。(※ このpip installの具体例だけではなくprivateレポジトリとのやり取りを行う処理の全般に使える。)

環境は以下の通り。(ただし、Macであれば他は問題にならないはず)

• Mac OS (10.14)
• サーバー: Ubuntu 16.04
• Docker 18.09 or higher (必須)

ssh-agentを使ってサーバー上でGithubにアクセス

普段手元のPCで使っている秘密鍵をサーバー上でも使えるようにする。

まずは秘密鍵を登録する。以下のコマンドで登録されているかどうかを確認できる。まだ何も登録していないので何も登録されていない。

$ ssh-add -l
The agent has no identities.

ここで秘密鍵の登録を行う。サーバー上でGithubとのやり取りを行いたいのでGithubに接続できる秘密鍵を選択する。Githubにsshアクセスできない方はGitHubでssh接続する手順~公開鍵・秘密鍵の生成から~でまずは登録を行う。

$ ssh-add ~/.ssh/id_rsa

これで登録ができるので、以下のように登録されていることが確認できる。

$ ssh-add -l
2048 xxx xxx/.ssh/id_rsa (RSA)

以上で秘密鍵が登録できたので、普段のssh接続のときに-Aのオプションをつけてアクセスする。

$ ssh -A xxx

サーバー上で以下のように打って、接続が確認できたら完了。

$ ssh -T git@github.com
Hi xxx! You've successfully authenticated, but GitHub does not provide shell access.

Docker build上でprivateレポジトリからpip install

Dockerfile サンプル

# syntax=docker/dockerfile:1.0.0-experimental

FROM ubuntu:16.04
ENV DEBIAN_FRONTEND noninteractive

RUN apt-get update && \
    apt-get install -y --no-install-recommends \
    build-essential \
    curl \
    git \
    libbz2-dev \
    libreadline-dev \
    libsqlite3-dev \
    libssl-dev \
    libcairo2-dev \
    libgirepository1.0-dev \
    make \
    openssh-client \
    python-dev \
    python-pip \
    vim \
    wget \
    zip \
    zlib1g-dev && \
    rm -rf /var/lib/apt/lists/*

ENV HOME /root

RUN git clone git://github.com/yyuu/pyenv.git $HOME/.pyenv
RUN git clone https://github.com/yyuu/pyenv-virtualenv.git $HOME/.pyenv/plugins/pyenv-virtualenv

ENV PYTHON_VERSION 3.6.8
ENV PYTHON_ROOT $HOME/local/python-$PYTHON_VERSION
ENV PYENV_ROOT $HOME/.pyenv
ENV PATH $PYENV_ROOT/shims:$PYENV_ROOT/bin:$PATH

RUN pyenv install 3.6.8
RUN pyenv global 3.6.8

RUN mkdir -m 700 $HOME/.ssh
RUN ssh-keyscan github.com > $HOME/.ssh/known_hosts
RUN --mount=type=ssh pip install git+ssh://git@github.com/xxx/xxx.git@vx.x.x

これを以下のようにbuildする。

$ export DOCKER_BUILDKIT=1
$ docker build -t xxx --ssh default .

Build-time secrets

docker buildを行うときにsecretsを使えるようになる機能。 Docker 18.09以降のバージョンが必要。以下のようにDockerfileの先頭に# syntaxの記述をすることと、対象となる行に--mount=type=sshをつけることでssh接続が実現できる。

# syntax=docker/dockerfile:1.0.0-experimental

RUN --mount=type=ssh xxx

また、実行時には以下のようにする。

$ export DOCKER_BUILDKIT=1
$ docker build -t xxx --ssh default .

ssh-keyscan

上記の処理だけだと接続時に以下のようなエラーが出てしまう。これはknown_hostsがうまく設定されていないからである。

Host key verification failed.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.

ssh-keyscanを使って以下のようにknown_hostsを設定してあげることでエラーは解消される。

RUN mkdir -m 700 $HOME/.ssh
RUN ssh-keyscan github.com > $HOME/.ssh/known_hosts

ssh-keyscanを使うためにはopenssh-clientをapt-getで入れておいてあげる必要があることに注意。

参考

• ssh-agentの使い方
• Docker Engine 18.09 から使える Build-time secrets を試してみた
• DOCKER BUILD LEARNS ABOUT SECRETS AND SSH AGENT FORWARDING
• Build secrets and SSH forwarding in Docker 18.09

原因

It looks like I may be the first to try and export nfs shares on macOS 10.15 Catalina. It’s borked. Work around: prefix your shared dir with /System/Volumes/Data/

i.e. change /etc/exports to
/System/Volumes/Data/usr/local -alldirs -mapall=501:20 192.168.99.100

— Matt Brenneke (@mbrennek) June 12, 2019

• NFS パスの先頭に /System/Volumes/Data/ をつけることで回避できる

対応手順

/etc/exports を編集する

要 root

/etc/exports_変更例.diff

- "/Users/user/hoge/fuga" localhost -alldirs -mapall=501:20
+ "/System/Volumes/Data/Users/user/hoge/fuga" localhost -alldirs -mapall=501:20

• パスの先頭に /System/Volumes/Data を追加した形
• nfsd checkexports でエラーがないか確認できる

変更を反映

sudo nfsd restart

• showmount -e でエクスポートしているディレクトリ一覧が確認できる
  • 何も出てこないと間違っている可能性がある

Docker や Vagrant の NFS 設定を更新

• NFS の設定パスの先頭に /System/Volumes/Data/ を追加
  • 下記は手元の docker-compose.yml の例
• 変更後 docker-compose を再読み込み

docker-compose.yml.diff

      driver: local
      driver_opts:
        type: nfs
        o: addr=host.docker.internal,actimeo=1
-       device: ":${PWD}/app/intentad"
+       device: ":/System/Volumes/Data${PWD}/app/hoge"

下記コマンドの中にはコンテナが稼働中だと削除できない場合があるので注意。
対象リソースに紐付くコンテナが稼働中の場合は、削除を行ってから対象リソースの削除を実施する。

Dockerの起動中のコンテナを削除する

docker rm -f $(docker ps -q)

Dockerの停止中のコンテナを削除する

docker rm -f $(docker ps -a -q)

Dockerのイメージをすべて削除する

docker rmi -f $(docker images -q)

Dockerのボリュームをすべて削除する

docker rm -f $(docker volume ls -q)

Dockerのネットワークをすべて削除する

docker rm -f $(docker network ls -q)

はじめに

本記事は、Oracle CloudでOracle Functionsを使用するための必要な設定方法について記載しています。

2019年8月1日に、正式サービスとしてOracle Cloudのサーバレスを実現するためのOracle Functionsと、Oracle Functionsで作成した関数をイベントドリブンで呼び出せるOracle Cloud Infrastructure Eventsのリリースが発表されました。

Oracle Functionsの公式マニュアルはWebから参照できますが、設定に関して一連の流れがまとまっていないため、初見の場合とても分かりずらいです。

本記事は、最短距離でOracle CloudのOracle Functionsを使用するための設定手順について簡潔にまとめています。

サーバレス

はじめに、サーバレスについて簡単に解説します。

一般的なサーバレスの技術は、FaaS（Function as a Service）として分類されます。
他のクラウドサービスで言うと、AWS Lambdaがメジャーです。

実行時間に応じて課金されるため、コード（関数）が実行されていないときには料金は発生しません。スクリプトの実行環境のみ提供されるので、IaaSに比べて大分保守コストは下がります。

実用的には、イベントに連動してトラフィックやパフォーマンスが求めれる、現代型のクラウドを使用したアーキテクチャと親和性が高い技術になります。

ホスティングするクラウドサービスも増えてきているので、サーバレスが進むと、システムの抽象化もより進み、インフラの概念は大きく変わることでしょう。

Oracle Functions

Oracle Functionsを使用するためには、Oracle FunctionsとOracle Cloud Infrastructure Eventsの設定が必要ですが、その他にも準備作業があります。

全体的に以下の作業が必要です。

1. アクセス権の設定
2. OCIRリポジトリの作成
3. Oracle Functionsの作成
4. Oracle Eventsの作成

本記事では、Oracle Functionsを使うために必要な上記、「アクセス権の設定」と「OCIRリポジトリの作成」について記載しています。

アクセス権の設定

ファンクションを作成するには、ユーザー・アカウントに、少なくとも1つのOCIRリポジトリと関連イメージに対するアクセス権が必要です。はじめに、アクセス権を設定するためのユーザを作成（※）します。

（※）既存ユーザを使用する場合は、ユーザ作成は不要

ユーザ

はじめに、Oracle Functionsで使用するユーザを作成します。
このユーザは、compartment単位で考えます。

また、APIの公開キーとトークンも合わせて設定します。

• APIの公開キー作成手順は、Required Keys and OCIDsを参照
• トークンの作成は、Docker CLIを使用したイメージのプッシュを参照

グループ

ユーザ作成後、ユーザが所属するグループを作成（※）し、グループに先ほど作成したユーザを追加します。

（※）既存グループを使用する場合は、ユーザ作成は不要

ポリシー

グループ作成後、親コンパートメントのポリシーに以下のポリシー・ステートメントを設定します。

allow group ＜グループ名＞ to manage repos in tenancy
allow group ＜グループ名＞ to manage cloudevents-rules in tenancy

• 設定画面

• 設定後の画面例

OCIRリポジトリの作成

次に、OCIRリポジトリと関連イメージを作成します。

OCIRリポジトリの作成

必要に応じて、OCIRリポジトリを作成します。
なお、OCIRリポジトリが存在しない場合は、docker pushコマンド実行時にリポジトリが作成されます。

イメージのアップロード

以下のコマンドを実行し、Oracle Cloud Infrastructure Registryにログインします。

# docker login nrt.ocir.io

Username: ＜コンパートメント名＞/＜リポジトリ名＞
Password: 
Login Succeeded

以下のコマンドを実行し、Oracle Cloud Infrastructure Registryにプッシュするタグをイメージに付けます。

# docker tag ＜コンテナID＞ nrt.ocir.io/＜コンパートメント名＞/＜リポジトリ名＞/＜イメージ名＞:＜タグ名＞

以下のコマンドを実行し、Oracle Cloud Infrastructure Registryにプッシュします・

# docker push nrt.ocir.io/＜コンパートメント名＞/＜リポジトリ名＞/＜イメージ名＞:＜タグ名＞

docker pushコマンドが失敗する場合は、ポリシーの設定に不備があります。ポリシーを設定しているコンパートメントの場所にも考慮が必要です。

• docker pushコマンド失敗の例

denied: User UserId(ocid1.user.***) cannot UploadDockerLayer on resource mytenant/myproject

おわりに

上記、準備作業が終わったら、Oracle Functionsの作成とOracle Eventsの作成を行います。

参考

• Policy Syntax
• Policies to Control Repository Access
• Create Policies to Control Access to Network and Function-Related Resources
• Events and IAM Policies
• レジストリの準備
• Docker CLIを使用したイメージのプッシュ

概要

• Dockerを使用したRailsの開発環境を構築
• DBはPostgreSQLを使用
• ローカル開発環境で構築(PostgreSQLのユーザー名、パスワードは簡易なものを使用)

＞＞MySQLはこちら

前提

• Mac、Windows10のローカル開発環境で動作
• 「Docker for Windows」か「Docker for Mac」がインストール済みであること

ディレクトリ構造

├─src
│  ├─Gemfile
│  └─Gemfile.lock
├─Dockerfile
└─docker-compose.yml

準備するファイル

ディレクトリ構造にある4つのファイルの内容は下記になります。

Dockerfile

Dockerfile

FROM ruby:2.6.3
ENV LANG C.UTF-8

RUN apt-get update -qq && \
    apt-get install -y build-essential \
            libpq-dev \
            nodejs

RUN mkdir /app
RUN mkdir /app/src

ENV APP_ROOT /app/src
WORKDIR $APP_ROOT

ADD ./src/Gemfile $APP_ROOT/Gemfile
ADD ./src/Gemfile.lock $APP_ROOT/Gemfile.lock

RUN bundle install


ADD . $APP_ROOT

docker-compose.yml(※WindowsとMacで記述を分ける箇所有)

docker-compose.yml

version: '3'
services:
  postgres:
    image: postgres
    ports:
      - "3306:3306"
    volumes:
      - ./tmp/db:/var/lib/postgresql/data #MacOSの場合
      - app_postgre:/var/lib/postgresql/data #Windowsの場合
    environment:
      POSTGRES_USER: 'admin'
      POSTGRES_PASSWORD: 'admin-pass'
    restart: always
  app:
    build: .
    image: rails
    container_name: 'app'
    command: bundle exec rails s -p 80 -b '0.0.0.0'
    ports:
      - "80:80"
    environment:
      VIRTUAL_PORT: 80
    volumes:
      - ./src:/app/src
    depends_on:
      - postgres
    restart: always

#下記はWindowsの場合追加
volumes:
  app_postgre:
    external: true

※PostgreSQLはWindowsではマウントできないようなので、参照先を外部に指定します。

Gemfile

src/Gemfile

source 'https://rubygems.org'
ruby '2.6.3'
gem 'rails', '5.2.3'

Gemfile.lock

ファイルの中身は空でOK

src/Gemfile.lock

手順

ボリューム作成(※Windowsの場合のみのコマンド)

$ docker volume create --name app_postgre

※PostgreSQLはWindowsではマウントできないようなので、参照先を外部にするためのコマンドです。

スケルトンアプリ作成

$ docker-compose run app rails new . --force --database=postgresql --skip-bundle

database.ymlを修正

src/config/database.yml

default: &default
  adapter: postgresql
  encoding: unicode
  # For details on connection pooling, see Rails configuration guide
  # http://guides.rubyonrails.org/configuring.html#database-pooling
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  username: admin
  password: admin-pass
  host: postgres

イメージ再ビルド

※処理完了までちょっと時間がかかることがあります。。。

$ docker-compose build

コンテナ立ち上げ

$ docker-compose up -d

PostgreSQLにRailsのDBを作成

$ docker-compose run app rails db:create

これで、http://localhostにブラウザでアクセスすると、Railsのインストール完了画面がでてきました。

トップページ作成

とりあえずトップページを表示させたい場合は下記コマンドを実行

$ docker-compose run app rails g controller Home top

「get 'home/top'」を「root to: 'home#top'」を変更

config/routes.rb

#　・・・

root to: 'home#top'

#　・・・

インストール後の作業

私の記事ですが、下記の手順もまとめましたので、参考にしていただければ幸いです。

【Rails】「config」の使い方 - Qiita
サイトから送信するSMTPサーバー情報や、ソーシャルログインなどで使用するAPIキーをGitにアップロードする際に、外部に情報が流出させないようにする設定です。

【Rails】Bootstrap4・jQueryを適用
フロントでBootstrap4とjQueryを適用して構築したい時は便利

Font Awesome適用
アイコンを気軽に使用したい時はこちらが便利。メールアドレスの登録・アンケート回答すると、無料でたくさんのアイコンが使用できます。

【devise】メール認証のサインアップ・イン・アウト機能
メール認証で、サイトに新規会員登録機能や、ログイン・ログアウト機能を搭載する設定です。

【Rails】【Devise】twitter・Facebookログイン実装
上記のメール認証に加えてソーシャルログイン機能を実装する手順です。