AWX にカスタム ansible環境を用意する。

Towerのドキュメントは

docs.ansible.com

こちらに。

  • local docker を利用している想定で話を進めていきます。
  • 利用する awx のバージョンは 5.0.0 ベースです。
  • 作成するvirtualenvは /var/lib/awx/venv/test で ansible 2.5.15 としています。

awx_web イメージの作成

適当なディレクトリ(/tmp/awx_web/)に Dockerfileを用意します。 あらかじめ、必要なモジュールをrequirements.txt として用意できると楽ですが、そうでなくてもがんばれはします。

ベースイメージは、オフィシャルに用意されているansible/awx_web:5.0.0を利用します。

FROM ansible/awx_web:5.0.0

USER 0
RUN yum -y install gcc python-devel && \
    python2 -m pip install virtualenv && \
    python2 -m virtualenv  /var/lib/awx/venv/test/ && \
    . /var/lib/awx/venv/test/bin/activate && \
    pip install python-memcached psutil "ansible == 2.5.15" && \
    yum -y remove gcc python-devel
USER 1000

このファイルを元に

docker build /tmp/awx_web/ -t test/aws_web:5.0.0 

とやって、 docker imageを作成します。

aws_task イメージの作成

適当なディレクトリ(/tmp/awx_task/)に Dockerfileを用意します。

ベースイメージは先ほど作成した test/awx_web:5.0.0 を利用します。

FROM test/awx_web:5.0.0

USER 0
RUN sudo yum -y remove nginx
USER 1000
EXPOSE 8052
CMD /usr/bin/launch_awx_task.sh

このファイルを元に

docker build /tmp/awx_task/ -t test/aws_task:5.0.0

とやって、 docker imageを作成します。

awxのインストールと実行

/tmp/awx ディレクトリに awxをclone します。

git clone https://github.com/ansible/awx /tmp/awx

local docker 用のインストーラーのインベントリファイル(/tmp/awx/installer/inventory)を編集します。

dockerhub_base=ansible

となっている箇所を dockerhub_base=test

と修正しましょう。 これは docker build -t test/awx_web:5.0.0 や docker build -t test/aws_task:5.0.0 とやったときの、 /より前のものです。今回は testとしましたね。 (通常は、docker hub の自分のアカウントを test の代わりに利用します。)

そして最後に

cd /tmp/awx/installer
ansible-playbook -i inventory installer.yml

で docker-compose を利用して awxを立ち上げます。

起動したら、試しにサンプルjob template をみてみると、

f:id:paihu:20190624115437p:plain

このように、 どのvirtualenvで実行するか選べるようになりました。

GitLabのバージョンアップをした話

概要

社内で9.0.xくらいのバージョンのGitLabを利用していました。

新規に追加された機能を利用したいという要望や、SaaSへ移行するタイミングが後ろにずれていったこと などがあり、最新バージョンに追随できるよう、バージョンアップを行いました。

なぜ

概要にも書きましたが、新規に追加された機能を利用したいというのが割と大きいです。アクセス権周りや、CI/CDに関する追加機能が利用できるようになるのがとても大きかったです。

スケジュール

まず、バージョンアップ自体が初めての経験だったので、公式マニュアルを見ながら、

  1. 9.x の最新バージョンにあげる
  2. 10.xの最新バージョンにあげ、11.xの最新バージョンにあげる

という2段階で行う計画を立てました。

実際の作業

下記の要領で行いました。

1回目

  1. 日程の調整を行い、作業日のアナウンス、

  2. データのバックアップ

  3. 9.x 最新バージョンへのアップデート

  4. 正常性の確認

2回目

  1. 日程の調整を行い、作業日のアナウンス、

  2. データのバックアップ

  3. 10.x 最新バージョンへのアップデート

  4. 正常性の確認

  5. 11.x 最新バージョンへのアップデート

  6. 正常性の確認

トラブルとか

9.x の最新版へアップデートした際、GitLab本体とは関係のないところでいくつかトラブルに見舞われました。

GitLabが動いているインスタンスIPアドレスが固定されておらず、 IPアドレス固定でアクセスしていた一部のジョブがコケるというのが一番大きく、 色々過去のことをよく知っている方と原因を探っていました。結局、 .ssh/config にIPアドレスが固定で記載されているという見つけにくいものが原因でした。

10.xへのアップデートは何事もなく終わり、11.xへのアップデート時に gitlab-ctl reconfigure が通らないという状況になり、 no implicit conversion of nil into String (#3189) · Issues · GitLab.org / omnibus-gitlab · GitLab を参考に gitlab.rb ファイルを修正し、 gitlab-ctl reconfigure を行い、正常にアップデートが完了しました。

どうなった

最新のGitLabを利用して開発が進められるようになりました。

また、GitLabでは、パッチバージョンについては、1つ前から最新へは無停止でのアップデートが可能なので、新しものが出るたびにきちんとアップデートしていけば、停止を伴う作業がなくなり、利用者の負担も無くせます。

より良い環境のために、きちんとバージョンアップはしていくことをお勧めします。

SPIFFEな勉強会でSPIFFE/SPIREとは何かを知った。

SPIFFEは、Zero Trust Networkを実現するための認証機構用APIとして生まれたらしいです。

何か、他のリソースへアクセスする機能を持ったものをWorkloadと呼び、そのWorkloadに対して、検証可能なTokenを付与することが主な責務です。

Workloadとして例えば、VM、container、functionなどが考えられます。

アクセスされる側もまたWorkloadの一つです。

あるWorkloadは、他のWorkloadにアクセスする際、Tokenをもって自分が何であるかを示します。 またアクセス先のWorkloadからもTokenを示してもらい、正しいアクセス先であることを知ることができます。

Tokenを発行するのがSPIFFEであり、Tokenを検証するのもSPIFFEです。 という感じです。

パブリッククラウドを利用しているとI AMという機能がありますが、それをGenericにしたものという理解は大体あってそうな気がしました。

SPIFFEでは、JWTとX.509の2つのTokenが今のところ策定されているので、Workload間で安全な通信を行うこともできるようになっています。

ではSPIFFEの参照実装であるSPIREはどうやってWorkloadに適切なTokenを割り当てるのかというと、そこはPlugin機構になっており、KubernetesAWSGCPなどのPluginが存在していて、 ようするにWorkloadの生成元からその情報をもらうということを行っています。

また、KubernetesAWSGCPそれぞれにSPIREを動作させ、それらの間でfederationすることで、相互にTokenの検証ができるようになります。

これができると、マルチクラウド、マルチクラスタ間で、Workload同士が互いに認証でき、また、セキュアな通信路で通信することができます。

SPIRE自体は、認証の大本となる情報を直接は保持しない作りになっているのもよいところだと思います。