docker の snap パッケージをプロキシ環境で使う方法と、 compose で build エラーになる話

本記事は、 Docker/コンテナ仮想環境 Advent Calendar 2024 - Qiita 5日目の記事だ。

Linux で docker をインストールする場合、どのようにしているだろうか?
OS 標準のパッケージマネージャーからのインストールが一般的? それとも、 Docker 公式のリポジトリ (Install - Docker Docs) を使っているだろうか?

そんな docker インストールする方法のひとつに Snap (Snapcraft) がある。

Snap (Snapcraft) とは

Snap (Snapcraft) は、Canonical が開発・管理している、アプリケーションをパッケージ化して配布するためのシステムのひとつだ。 Canonical は Ubuntu を支援している企業だが、 Ubuntu 以外の多くの主要なディストリビューションでも Snap を利用できる。

依存関係を含む一式がコンテナ化されており、異なる Linux ディストリビューション間で共通のパッケージで動作するのが特徴だ。 サンドボックス化したファイルシステム内でインストールしたアプリケーションを動かすという、セキュリティ面の特徴もある。

snap 版 docker は、 /home/ 以下のファイルしか参照できない強い制限 1 や、インストール時に docker グループを作成してくれない制限があるが、それ以外はわりと問題なく動く。

Snap 版 docker に於けるプロキシ設定手順

プロキシの設定さえ適切に行えば、 snap 版 docker もプロキシ環境下で動作する。

基本的な設定箇所は、 Docker DaemonDocker CLI の設定と同じだが、前述のサンドボックス化の関係で、記述するファイルの場所が異なる。

具体的には

  • /etc/docker/daemon.json の替わりに /var/snap/docker/current/config/daemon.json
  • ~/.docker/config.json の替わりに ~/snap/docker/current/.docker/config.json

をそれぞれ書き換える。

特に後者 (~/snap/docker/current/* 以下) については、一度そのユーザーで何らかの docker コマンド (後述の例では docker info) を実行してから設定しなくてはならない。
そうしないと、フォルダが Snap サンドボックスへマッピングされないからだ。

では、インストールからの手順を追ってみよう

続きを読む

k8s ミリしら向けの AWX on MicroK8s with プロキシ

Docker ぐらいならなんとかわかるけど、 Kubernetes (k8s) は全然わかっていない人向けに、プロキシ環境下の MicroK8s 上で AWX をインストールする手順と、その周囲情報を説明していく。

AWX とは

AWX とは、 Ansible Automation Controller (旧称: Ansible Tower) と呼ばれる Ansible の構成コードの実行を管理する WebUI を持ったツールの OSS版だ。

Ansible とは IaC (Infrastracture as Code) ができる CUI ツールであり、構成先に Python さえ入っていれば、そこに ssh するだけで実行できるのが特徴だ。
AWX はこれを Git などのソースコード管理ツールと連携しながら、 Web UI 上で実行・管理・記録できるツールとなる。

Ansible Automation Controller と比べると、 Red Hat によるサポートや LTS はなく、 ローリングリリースモデルを採用していて更新が激しい。
このため、エンタープライズ用途には基本的には向かないものの、元々そんなに破壊的変更が頻繁にあるタイプのツールではないため、小規模に使う程度ならかなり実用的になっている。
(但し 2024年9月現在、次回のメジャー更新の v25 あたりで、認可・認証の内部構成が大きく変わる予定ではある 1)

Kubernetes と MicroK8s

AWX を運用環境にインストールするには、 Kubernetes が必須となっている。

Kubernetes (多くは K8s と略される) は、コンテナ管理ツールのひとつで、コンテナオーケストレーションツールとも呼ばれる。

コンテナ管理といえば、 Docker が非常に有名だ。
Docker はどちらかというと開発者よりのツールで、一つのコンテナないし、 Docker Compose を使って一つのホスト(マシン)内に閉じた複数のコンテナの管理に特化している。

一方、多少規模のあるサービスをコンテナで運用する場合、複数ホストにまたがっていくつものコンテナを協調動作させる場合が多い。

Kubernetes であれば複数のホストに跨がって複数のコンテナを協調操作させる運用管理ができる。
例えば・・・

  • 異なるホストで動作しているコンテナを、同じ仮想ネットワークにあるかのように扱う
  • 負荷に応じてコンテナをスケーリングする
  • コンテナ起動やダウン時の自己修復や負荷分散のロジック等を自分で作り込む

といった事ができる。

続きを読む

MicroK8s で kustomization.yaml を apply すると error: accumulating resources になる問題

MicroK8s で kustomization.yaml を apply した際に、 error: accumulating resources が発生する問題についてのメモ。

端的に言うと、snap でインストールした MicroK8s で、内部的に git コマンドが実行される操作をすると、おかしくなる模様。

発生する問題

snap で MicroK8s をインストールし、 kubectl apply -k する。
このとき、Kustomize に指定する kustomization.yaml には、直接的または間接的に remote directory 方式のリソースを参照する。

$ sudo snap install microk8s --classic --channel=latest/stable
$ cat << EOF > ./kustomization.yaml
resources:
- https://github.com/kubernetes-sigs/kustomize//examples/helloWorld/?timeout=120&ref=v3.3.1
EOF
$ microk8s kubectl apply -k .

すると、以下のようなエラーが発生する。

ホストOS に git がインストールされている場合:

error: accumulating resources: accumulation err='accumulating resources from 'https://github.com/kubernetes-sigs/kustomize//examples/helloWorld/?timeout=120&ref=v3.3.1': URL is a git repository': failed to run '/snap/microk8s/6364/usr/bin/git fetch --depth=1 https://github.com/kubernetes-sigs/kustomize v3.3.1': /usr/lib/git-core/git-remote-https: symbol lookup error: /snap/core20/current/lib/x86_64-linux-gnu/libpthread.so.0: undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE
: exit status 128

ホストOS に git がインストールされていない場合:

error: accumulating resources: accumulation err='accumulating resources from 'https://github.com/kubernetes-sigs/kustomize//examples/helloWorld/?timeout=120&ref=v3.3.1': URL is a git repository': failed to run '/snap/microk8s/6364/usr/bin/git fetch --depth=1 https://github.com/kubernetes-sigs/kustomize v3.3.1': fatal: unable to find remote helper for 'https'
: exit status 128

ワークアラウンド

続きを読む