zaki work log

作業ログやら生活ログやらなんやら

[Linux] ProxyJump設定でSSHの多段アクセスとscp/ポートフォワード

検証環境へアクセスするために踏み台サーバ―を経由しないとアクセスできないとか、踏み台サーバーを3つ経由しないと本番環境へアクセスできないとか、そんな場合でもsshで1コマンドでアクセスするためのオプション指定について、man sshを眺めていたらたまたまProxyJumpというオプションが目に留まったので確認してみた。

環境

ローカルホストから、

  1. ssh 192.168.0.16 (踏み台1)
  2. ssh 172.16.1.0 (踏み台2)
  3. ssh 172.29.0.89 (お目当てのターゲットホスト)

という順序でSSHアクセスしたい場合、以前は(というより今でも多くのところで)ProxyCommandを使って多段アクセスしていたが、(2016年リリースのOpenSSH 7.3で)ProxyJumpオプションが追加されており、このオプションを使うとより簡潔なオプション指定で多段アクセスを実現できる。

図にするとこんな構成。

ProxyJumpを使った多段アクセス

[zaki@cloud-dev ~]$ ssh 172.29.0.89 -J 192.168.0.16,172.16.1.0
zaki@192.168.0.16's password: 
zaki@172.16.1.0's password: 
zaki@172.29.0.89's password: 
Last login: Wed Feb  2 21:10:16 2022 from 172.29.0.10
[zaki@restricted-node ~]$
[zaki@restricted-node ~]$ ip a s ens192
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0c:29:77:f6:c4 brd ff:ff:ff:ff:ff:ff
    inet 172.29.0.89/24 brd 172.29.0.255 scope global noprefixroute ens192
       valid_lft forever preferred_lft forever

この通り、-Jオプションにアクセスしたい順番にカンマ区切りで踏み台ホストを羅列すれば、記述した順序でSSHアクセスして最終的にお目当てのターゲットホストへログインする動作になる。

ユーザー名やポートが異なるサーバーがある場合

踏み台の特定ホストだけユーザー名やポート番号を指定する場合は、username@host:portの書式で記述する。
途中の踏み台の172.16.1.025022でListenしていて、さらにsample-userユーザーでアクセスする場合は以下の通り。

[zaki@cloud-dev ~]$ ssh 172.29.0.89 -J 192.168.0.16,sample-user@172.16.1.0:25022
zaki@192.168.0.16's password: 
sample-user@172.16.1.0's password: 
zaki@172.29.0.89's password: 
Last login: Wed Feb  2 21:10:49 2022 from 172.29.0.10
[zaki@restricted-node ~]$ 

鍵認証

ここまでの例はコマンド実行例からも分かる通り、パスワード認証でログインしている。
公開鍵認証については、ドキュメントからはちょっと読み取れなかったけど、コマンドラインオプションで指定できる秘密鍵は、お目当てのターゲットホストに登録してある公開鍵のみに作用している。
踏み台サーバーの鍵認証用の秘密鍵コマンドラインでは指定できなさそう。

ターゲットホストとの公開鍵認証はオプション指定で従来通り特に問題なく実行できる。
ローカルにある秘密鍵~/.ssh/id_rsa_4096の公開鍵が、ターゲットホストの~/.ssh/authorized_keysに登録済みであれば、以下の通り。

[zaki@cloud-dev ~]$ ssh 172.29.0.89 -J 192.168.0.16,sample-user@172.16.1.0:25022 -i ~/.ssh/id_rsa_4096
zaki@192.168.0.16's password: 
sample-user@172.16.1.0's password: 
Last login: Wed Feb  2 21:18:53 2022 from 172.29.0.10
[zaki@restricted-node ~]$ 

172.29.0.89アクセス時のパスワード認証が行われず、鍵認証でログインできている。
踏み台サーバーも鍵認証を行いたい場合は、少なくともssh_configに記述すれば可能。

ssh_config基本

まずは鍵認証なしの場合の記述。
踏み台2つ目以降は、その前段の踏み台のホストが何かをproxyjumpの行に記述する。

Host proxy1
    hostname 192.168.0.16
Host proxy2
    hostname 172.16.1.0
    user sample-user
    port 25022
    proxyjump proxy1
Host target
    hostname 172.29.0.89
    proxyjump proxy2

踏み台サーバーへの秘密鍵の指定がある場合は、それぞれ指定すればOK

Host proxy1
    hostname 192.168.0.16
    identityfile ~/.ssh/id_rsa_4096
Host proxy2
    hostname 172.16.1.0
    user sample-user
    port 25022
    identityfile ~/.ssh/id_rsa_nopass
    proxyjump proxy1
Host target
    hostname 172.29.0.89
    identityfile ~/.ssh/id_rsa_4096
    proxyjump proxy2

それぞれ対応した公開鍵をそれぞれのホストに登録してあれば、ターゲットホストへのSSHアクセスのコマンドで一気にログインできる。
(パスフレーズが設定されてればもちろん入力は必要だけど)

[zaki@cloud-dev ~]$ ssh target 
Last login: Wed Feb  2 21:36:41 2022 from 172.29.0.10
[zaki@restricted-node ~]$ 

ポートフォワード

ターゲットホスト上からlocalhost:8888でアクセスできるwebサーバーがあるとして、このwebサーバーにSSHを実行するローカルからアクセスしたい場合について。といっても、通常のローカルポートフォワードと同じく-Lを使えばOK。
ローカルホストの8889/TCPをターゲットのlocalhost:8888にフォワードするには、-L 8889:localhost:8888を指定する。

[zaki@cloud-dev ~]$ ssh 172.29.0.89 -J 192.168.0.16,sample-user@172.16.1.0 -L 8889:localhost:8888
zaki@192.168.0.16's password: 
sample-user@172.16.1.0's password: 
zaki@172.29.0.89's password: 
Last login: Wed Feb  2 23:08:47 2022 from 172.29.0.10
[zaki@restricted-node ~]$

この状態で確認用webサーバーを起動。

[zaki@restricted-node ~]$ ls -aF
./  ../  .bash_history  .bash_logout  .bash_profile  .bashrc  .ssh/
[zaki@restricted-node ~]$ python -m SimpleHTTPServer 8888
Serving HTTP on 0.0.0.0 port 8888 ...

これで、SSH接続元のブラウザでlocalhost:8889にアクセスすると、ターゲットホストのlocalhost:8888フォワードされる。

ターゲットホストに対するローカルポートフォワード込みのssh_configは以下の通り。
(踏み台の記述は変更無し)

Host target
    hostname 172.29.0.89
    identityfile ~/.ssh/id_rsa_4096
    proxyjump proxy2
    localforward 8889 localhost:8888

※ SimpleHTTPServerについては以下参照。

qiita.com

scpの多段転送

[zaki@cloud-dev ~]$ scp ./kubeconfig.yaml target:/var/tmp

ssh_configが設定されていれば、これで一気にターゲットホストへ転送できる。
ホップ数によってはこれがかなり便利。

ssh_config設定無しでコマンドラインオプションで指定するには、scpには-Jオプションがないため、-oProxyJumpを指定する。(※ 後述)

[zaki@cloud-dev ~]$ scp -o 'ProxyJump 192.168.0.16,sample-user@172.16.1.0' ./kubeconfig.yaml 172.29.0.89:/var/tmp
zaki@192.168.0.16's password: 
sample-user@172.16.1.0's password: 
zaki@172.29.0.89's password: 

2023.08.01追記:
scpにもOpenSSH 8.0で-Jオプションに対応していた模様。ssh-Jと同様に踏み台の指定を行う。
ただし現時点(OpenSSH 8.8)では、-Jオプションを転送元・転送先ファイル名の後に指定すると踏み台の指定がファイル名と認識されてしまうため、コマンドの直後に指定する。

### 後ろにオプション指定した場合
$ scp ./memo.md  172.16.1.3:~ -J 192.168.0.16
192.168.0.16: No such file or directory

### 先にオプション指定した場合
$ scp -J 192.168.0.16 ./memo.md  172.16.1.3:~
zaki@172.16.1.3's password: 

WindowsSSH

動作する。

PS C:\Users\zaki> ssh -V
OpenSSH_7.7p1, OpenSSL 1.0.2o  27 Mar 2018
PS C:\Users\zaki> ssh 172.29.0.89 -J 192.168.0.19,172.16.1.0
zaki@192.168.0.19's password:
zaki@172.29.0.89's password:
Last login: Sat Jan 29 20:13:16 2022 from 172.29.0.10
[zaki@restricted-node ~]$

5年以上前に機能追加されてたなんて知らなかった。。
ついでにいうとssh-copy-idコマンドもしばらく知らなかった←

[Ansible Builder]パッケージインストールに追加のリポジトリ設定やファイルコピーが必要な場合のイメージビルド

本記事はAnsible Advent Calendar 2021の14日目のエントリです。
珍しくインプットが湧いてきた1ため2日連続です笑

adventar.org

環境その他もろもろは、以前Ansible Builderについて試したこの記事のときのものと同じです。

解決したい課題

7月に一度、新しいAnsibleの実行環境であるExecution Environment(以下EE)をお試し実行してみましたが、この時「OSパッケージインストール周りでリポジトリ追加したい場合なんかは現状不明。」という課題を残したまま放置してました。

zaki-hmkc.hatenablog.com

当時は「イメージ内に追加で必要なパッケージはbindep.txtに記述する」機能から発想が縛られて、「一度ビルドを実行すると生成されるcontext/Containerfileファイルがあるため、内容を書き換えて(as builderの後にリポジトリを追加する処理を差し込む)リビルド」というかなり無理やりなことをしていました。

というのも、EEの定義ファイル(デフォルトexecution-environment.yml)にパッケージインストール関連で記載できるのはbindep.txtにパッケージ名、あとリポジトリの変更を行いたければadditional_build_steps以下に記載はできるけど、肝心の処理順序が「bindepによるパッケージインストール」が先で、「additional_build_stepsprependの処理」が後(※)のため、bindep.txtリポジトリ追加が必要なパッケージを記載しても、そのリポジトリ追加を行うタイミングが無い、というモノでした。(鶏卵 ちょっと違うか…)

※12/14夜追記: 正確には、イメージビルドの内訳として、builderのイメージビルド(FROM $EE_BUILDER_IMAGE as builderの部分)と、runnerのイメージビルド(FROM $EE_BASE_IMAGEの部分)があり、最後のrunnerのイメージビルドはadditional_build_stepsに記述した処理のあとにbindep.txtを参照したパッケージインストールが行われるので期待通りの動きをするが、中間にあるbuilderのイメージビルドはadditional_build_stepsの処理は行わずにbindep.txtを使ったパッケージインストールを行う処理内容になっている。詳細はビルド時に生成されるContainerfileを参照。

回避策

実際のところ、Execution Environment Definitionを見ても、リポジトリ設定の余地は現状ないので、機能的には無さそう。

ansible-builder.readthedocs.io

ただ、そもそも7月の時点でどうして思いつかなかったんだ、というレベルだったりするけど、additional_build_stepsの中で、

  1. リポジトリを追加する処理
  2. 追加したリポジトリからパッケージインストールする処理

をどちらも書いてしまえばいいじゃん、というのを思いついたのでお試し。

お題は前回と同じくKubernetesCLIコマンドのインストール。

execution-environment.yml (抜粋)

additional_build_stepsの部分は以下の通り。

additional_build_steps:
  prepend:
    - COPY kubernetes.repo /etc/yum.repos.d/kubernetes.repo
    - RUN dnf install -y kubectl

Kubernetesのドキュメントではcatとヒアドキュメントでファイル生成してるけど、ちょっとコツがいるので素直に外部ファイル化してCOPY使っている。
(これはこれでコツがいるんだけど…後述)

なお、EEのベースイメージはCentOSベースなので、パッケージもCentOSの場合の手順を実施。

kubernetes.repo (追加ファイル)

これはドキュメントの通りの内容。
インライン記載は後述してるけど、別途ファイル用意した方が(今回の場合は)ミスは少ないと思う。

[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

ビルド

execution-environment.ymlなどの制御に使用するファイル以外の、イメージ内部に追加したい(今回のkubernetes.repoファイルのような)追加ファイルがある場合は、ビルド時にコンテキストの指定が必要。

$ ansible-builder build --help

  [...]

  -c BUILD_CONTEXT, --context BUILD_CONTEXT
                        The directory to use for the build context (default: context)

これはデフォルドではcontextというディレクトリが指定されるが、このディレクトリがビルド時のルートディレクトリとして扱われるイメージ。もっといえば、ここがchrootされる感じ。
つまり、イメージへ追加したいファイルがある場合は、コンテキストで指定したディレクトリ以下になければ、ビルド時にファイルを(例えフルパスで指定してたとしても、ビルド時のルートはコンテキストで指定したディレクトリになるため)認識できない。

よって、具体的なコマンドラインは、execution-environment.ymlkubernetes.repoのあるディレクトリで以下の通り。

$ ls -F
Containerfile  bindep.txt                 kubernetes.repo   requirements.yml
ansible.cfg    execution-environment.yml  requirements.txt
$ ansible-builder build --tag kube-sample:devel --context .

これで、イメージビルド時のCOPYの対象であるkubernetes.repoを認識してイメージへコピーできるようになる。

ファイル数が多く、execution-environment.ymlなどとは分離したい場合は、「イメージへ組み込みたいファイル用のディレクトリを作成し、--contextでそのディレクトリを指定」すればOK.
その場合でも、COPYの引数に指定するファイルのパスは、--contextで指定するディレクトリ基準の相対パスにすれば良い。

確認

$ ansible-builder build --tag kube-sample:devel --context files
Running command:
  podman build -f files/Containerfile -t kube-sample:devel files
Complete! The build context can be found at: /home/zaki/ee/kube/files
$ podman run -it --rm localhost/kube-sample:devel bash
bash-4.4# cat /etc/yum.repos.d/kubernetes.repo 
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
bash-4.4# kubectl version --short --client
Client Version: v1.23.0

ちゃんとできている。

ヒアドキュメントは…無理かな?

これはダメだった例。

  prepend: |
    COPY <<EOF /etc/yum.repos.d/kubernetes.repo
    [kubernetes]
    name=Kubernetes
    baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
    enabled=1
    gpgcheck=1
    repo_gpgcheck=1
    gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
    EOF

これはワンチャン行けるかなと思ったけど、構文エラーにはならずビルドは動いて、COPYのタイミングで「<<EOFというファイルが無い」というエラーとなった。

STEP 17: COPY <<EOF /etc/yum.repos.d/kubernetes.repo
Error: error building at STEP "COPY <<EOF /etc/yum.repos.d/kubernetes.repo": checking on sources under "/home/zaki/ee/kube/context": copier: stat: "/<<EOF": no such file or directory

インラインでやるならこんな感じ。
echo-eオプションを付加し、\nで改行しつつ、行末の\で次行へ続ける記述でファイル作成を確認。

  prepend: |
    RUN echo -e "[kubernetes]\n\
    name=Kubernetes\n\
    baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64\n\
    enabled=1\n\
    gpgcheck=1\n\
    repo_gpgcheck=1\n\
    gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg" > /etc/yum.repos.d/kubernetes.repo
    RUN dnf install -y kubectl

確認した環境

$ cat /etc/redhat-release 
Fedora release 34 (Thirty Four)
$ ansible-builder --version
1.0.1
$ python --version
Python 3.9.4

おまけというか備忘録
additional_build_steps以下prependへのコマンドの指定は、リストでも複数行テキストでもどっちでもOKでした。


  1. 同じシチュエーションの対応策に困ってる部署のメンバがいて、回避策を偶然思いついた、というものw やはり業務を通して(にゃーん

[Ansible] fetchモジュールを使ってリモートのファイルを実行ノードへ転送・集約する

最近アウトプットできてなかったけど、これはAnsible Advent Calendar 2021の13日目のエントリです。

adventar.org

個人的にあまりなじみがないfetchモジュールについての備忘録です。
このモジュールはcopyモジュールの逆で、マネージドノード上のファイルをコントロールノードへコピーします。システム構築の自動化でAnsaibleを使うようなシチュエーションだと割と使用頻度が低い(個人の感想)のですが、サービスの日々の運用で、各ホスト上の例えばログファイルを1か所へ集約したい場合に本領を発揮します(当社比)。

docs.ansible.com

基本の使い方

  tasks:
    - name: fetch file
      ansible.builtin.fetch:
        src: /var/log/messages
        dest: /var/tmp/fetch-test

モジュールの基本機能は、リモートホストsrcに指定したファイルを、Ansible実行ホストのdestで指定したディレクトリ以下にリモートホスト名/リモート上のフルパスというパスでコピーする。
このとき、destディレクトリが無くても自動で作成される。

flatパラメタ

コピー時のリモートのパスやリモートホスト名が不要で、destに指定したパスに直接集めたい場合は、flatパラメタを指定する。

    - name: fetch file
      ansible.builtin.fetch:
        src: /var/log/messages
        dest: /var/tmp/fetch-test
        flat: true

flatパラメタをtrueにすると、destに指定したパスが転送先になる。
この例だと、リモートの/var/log/messagesファイルは/var/tmp/fetch-testというファイル名で転送される。

また、

    - name: fetch file
      ansible.builtin.fetch:
        src: /var/log/messages
        dest: /var/tmp/fetch-test/  # '/' 追加
        flat: true

このようにdestの指定をディレクトリ(末尾/)にすると、ファイル名は維持され転送先は/var/tmp/fetch-test/messagesになる。

ただしflatを使う場合、処理対象のホストが複数ありファイル名が同一だとすべて同じファイルで転送されるため、処理順が最後のホスト以外のファイルは上書きされてしまうので注意。
flatを使用しつつ、ファイル名にホスト名を付与したいのであれば、マジック変数のinventory_hostnameを使うなどしてパスやファイル名がホスト毎になるように調整する。

        dest: "/var/tmp/fetch-test/{{ inventory_hostname }}/"

docs.ansible.com

fail_on_missingパラメタ

デフォルトの動作は、リモートホスト上にsrcで指定したファイルが無い場合は失敗となる。
要件によって「ファイルが無い場合は何もしない(正常完了)」したい場合は、fail_on_missingパラメタにfalseを指定する。
(ファイルが存在しない場合以外の転送失敗なども軒並み無視するignore_errorsなどを使わないよーに)

    - name: fetch file
      ansible.builtin.fetch:
        src: /var/log/messages
        dest: /var/tmp/fetch-test
        fail_on_missing: false

このオプションは、古いAnsibleバージョンだとデフォルト値が逆になっているので(バージョン塩漬けのような)環境によっては動作が異なるので注意。

ディレクトリ以下を再帰的にコピーするには…

fetchモジュールには再帰コピーの機能はない1ため、自力で処理する必要がある。
ファイルリストを作成するにはfindモジュール辺りを使ったタスクを別途用意する。

    - name: create file list
      ansible.builtin.find:
        paths: /var/log
        recurse: true
      register: register_file_stat

    - name: fetch files
      ansible.builtin.fetch:
        src: "{{ item }}"
        dest: /var/tmp/fetch-test
      loop: "{{ register_file_stat.files | map(attribute='path') }}"

ただしこのとき、ファイル数やサイズが大量で転送に時間がかかる場合でかつ、リモートホスト上のファイルの作成や削除が頻繁に発生するような環境の場合、リスト作成時点から転送までのタイムラグによってファイルの有無が変化すると転送失敗になったりするので注意が必要。

対象ディレクトリをarchiveモジュールでファイルに固めて転送する方が良い場合もあるので、要件によって検討する。
手順は増えるが、転送後のアーカイブファイルの展開と削除も必要に応じて行う。

    - name: archive files
      community.general.archive:
        path: /var/log
        dest: /tmp/log.tar.gz

    - name: fetch file
      ansible.builtin.fetch:
        src: /tmp/log.tar.gz
        dest: /var/tmp/fetch-test

ちなみにarchiveモジュールは普段使わないから気付かなかったけど、アーカイブ対象に変化が無かったら実行ステータスはokになって冪等性が担保されるように見えるけど、その場合でもアーカイブファイルのタイムスタンプが更新されてしまうため、その後のタスクの冪等性を担保するのはすこし難しいかも。
(ファイルの更新は最新のcommunity.general 4.1.0でも再現)

ただ、「定期実行でそのタイミングのスナップショット的にファイル構造を丸ごと保存したい」みたいな要件の場合は、アーカイブ式の方が扱いやすいかも。

環境

$ ansible --version
ansible [core 2.11.3] 
  config file = /home/zaki/.ansible.cfg
  configured module search path = ['/home/zaki/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/zaki/venv/ansible4.2.0/lib64/python3.9/site-packages/ansible
  ansible collection location = /home/zaki/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/zaki/venv/ansible4.2.0/bin/ansible
  python version = 3.9.2 (default, Mar  5 2021, 01:49:45) [GCC 8.4.1 20200928 (Red Hat 8.4.1-1)]
  jinja version = 3.0.1
  libyaml = True


  1. 現状のモジュールのドキュメントに「Recursive fetching may be supported in a later release.」とそのうち実装されるかも的な記述はあるけど。

[Oracle Linux] arm64アーキテクチャのA1.FlexのVMでDocker版NetBoxをビルド&デプロイする (Ubuntu / Oracle Linux)

Oracle Cloudで無料で使えるA1.FlexシェイプのVM(arm64アーキテクチャ)でNetBoxをDockerでデプロイしてみました。
NetBoxのコンテナイメージはamd64版しか公開されていないため、arm64アーキテクチャでコンテナ版をデプロイするには、自前でビルドする必要があります。 ただ、ビルドのためのスクリプト類は用意されてるので、簡単にビルドできます。

ビルド自体は以前試したここの手順の通りで、NetBox本体のリポジトリのtag名などを指定すれば、そのバージョンのイメージをビルドできます。

zaki-hmkc.hatenablog.com

Oracle Cloud A1.FlexのインスタンスへのDockerエンジン本体のインストールはこちら
Docker Composeのインストールはpip版Docker Plugin版どちらかでインストールする。本エントリではDocker PluginとしてインストールしたCompose v2でお試し。

Ubuntu 20.04 / Oracle Linux 8

$ git clone -b release https://github.com/netbox-community/netbox-docker.git
$ cd netbox-docker/

で、本来であれば必要に応じてdocker-compose.override.ymlを用意したりし、upすればデプロイできるのですが、

netbox-docker-netbox-1               | standard_init_linux.go:228: exec user process caused: exec format error
netbox-docker-netbox-1 exited with code 1

起動に失敗します。
これは、NetBoxのコンテナイメージがamd64向けしか公開されておらず、でも実行しようとしてるプラットフォームはarm64のため起動に失敗している状態のため、何をどう頑張っても起動できません。

f:id:zaki-hmkc:20210930230153p:plain

$ docker run --rm netboxcommunity/netbox:v3.0 
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
standard_init_linux.go:228: exec user process caused: exec format error

じゃあどうすればいいかと言うと、実行したいプラットフォーム用のイメージを自分でビルドすれば(今回動かしたいNetBoxについては)OKです。
NetBoxのコンテナイメージは、(わかりにくいけど)alpineがベースイメージになっていて、このイメージはarm64用が用意されているため、このイメージをベースにビルドします。特定プラットフォーム用のビルドというとクロスコンパイルみたいなイメージがありますが、単に動かしたいarm64のプラットフォーム(のDockerエンジン)上でビルドすればOKです。

f:id:zaki-hmkc:20210930230417p:plain

NetBoxのコンテナイメージビルドは、デプロイに使用するComposeファイルを提供しているnetbox-dockerリポジトリに、ビルド用のスクリプトも同梱しているため、そのスクリプトを実行すればよいので簡単にビルドできます。

github.com

2021.09.30時点で最新のv3.0.4でお試し。
ビルドスクリプトの引数に、NetBox本体のリポジトリのターゲットバージョンのtagを指定します。

github.com

$ ./build.sh v3.0.4

ビルドはこれだけ。そこそこ時間かかる。
ビルド完了すると以下の通り。

$ docker image ls
REPOSITORY               TAG           IMAGE ID       CREATED         SIZE
netboxcommunity/netbox   latest-ldap   955e60dabcfc   4 minutes ago   442MB
netboxcommunity/netbox   v3.0-ldap     955e60dabcfc   4 minutes ago   442MB
netboxcommunity/netbox   v3.0.4-ldap   955e60dabcfc   4 minutes ago   442MB
netboxcommunity/netbox   latest        cffca943100b   4 minutes ago   436MB
netboxcommunity/netbox   v3.0          cffca943100b   4 minutes ago   436MB
netboxcommunity/netbox   v3.0.4        cffca943100b   4 minutes ago   436MB

v3.0のタグを含めてビルドできてるので、そのままdocker compose upします。
(標準で用意されているdocker-compose.ymlv3.0タグ前提の記述なので)

$ docker compose up 
[+] Running 6/6
 ⠿ Container netbox-docker-redis-cache-1          Creat...                                         0.0s
 ⠿ Container netbox-docker-postgres-1             Created                                          0.0s
 ⠿ Container netbox-docker-redis-1                Created                                          0.0s
 ⠿ Container netbox-docker-netbox-housekeeping-1  Recreated                                        0.1s
 ⠿ Container netbox-docker-netbox-worker-1        Rec...                                           0.1s
 ⠿ Container netbox-docker-netbox-1               Recreated                                        0.1s
Attaching to netbox-docker-netbox-1, netbox-docker-netbox-housekeeping-1, netbox-docker-netbox-worker-1, netbox-docker-postgres-1, netbox-docker-redis-1, netbox-docker-redis-cache-1
netbox-docker-redis-cache-1          | 1:C 30 Sep 2021 12:11:13.783 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo

[...]

netbox-docker-netbox-1               | ✅ Initialisation is done.
netbox-docker-netbox-1               | ⏳ Waiting for control socket to be created... (1/10)
netbox-docker-netbox-1               | 2021/09/30 12:12:15 [warn] 7#7 Unit is running unprivileged, then it cannot use arbitrary user and group.
netbox-docker-netbox-1               | 2021/09/30 12:12:15 [info] 7#7 unit started
netbox-docker-netbox-1               | 2021/09/30 12:12:15 [info] 20#20 discovery started
netbox-docker-netbox-1               | 2021/09/30 12:12:15 [notice] 20#20 module: python 3.9.5 "/usr/lib/unit/modules/python3.unit.so"
netbox-docker-netbox-1               | 2021/09/30 12:12:15 [info] 7#7 controller started
netbox-docker-netbox-1               | 2021/09/30 12:12:15 [notice] 7#7 process 20 exited with code 0
netbox-docker-netbox-1               | 2021/09/30 12:12:15 [info] 22#22 router started
netbox-docker-netbox-1               | 2021/09/30 12:12:15 [info] 22#22 OpenSSL 1.1.1l  24 Aug 2021, 101010cf
netbox-docker-netbox-1               | ⚙️ Applying configuration from /etc/unit/nginx-unit.json
netbox-docker-netbox-1               | 2021/09/30 12:12:16 [info] 26#26 "netbox" application started
netbox-docker-netbox-1               | 🧬 loaded config '/etc/netbox/config/configuration.py'
netbox-docker-netbox-1               | 🧬 loaded config '/etc/netbox/config/extra.py'
netbox-docker-netbox-1               | 🧬 loaded config '/etc/netbox/config/logging.py'
netbox-docker-netbox-1               | 🧬 loaded config '/etc/netbox/config/plugins.py'
netbox-docker-netbox-1               | ✅ Unit configuration loaded successfully
netbox-docker-netbox-1               | 2021/09/30 12:12:18 [notice] 7#7 process 18 exited with code 0

はい。
あとはセキュリティグループなどの設定を確認しつつwebアクセスすればこの通り。

f:id:zaki-hmkc:20210930230721p:plain

Oracle Linux 7.9の場合

Gitバージョンでトラップあるので注意。
それ以外はUbuntu 20.04 / Oracle Linux 8と同じ。

$ ./build.sh v3.0.4
▶️ ./build.sh v3.0.4
🌐 Checking out 'v3.0.4' of NetBox from the url 'https://github.com/netbox-community/netbox.git' into '.netbox'
Note: checking out '84d83fbd143f26097db9464a46657b7a65ab27cb'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

fatal: git fetch-pack: expected shallow list

標準リポジトリyum installできるGitのバージョンが1系のため、必要な操作ができないエラーになります。

$ git version
git version 1.8.3.1

IUSのリポジトリからインストールできたら簡単かな?と思ったけど、あいにくこのリポジトリではarm64版のパッケージはありません。
探した結果、Oracle Linux 7.9では標準リポジトリrh-git218-git-all.noarchというパッケージが用意されています。(名前…いいのかな、これw)

$ sudo yum install rh-git218-git-all

このパッケージをインストールすると、/opt/rh/rh-git218/root/usr/bin/gitにv2系のGitがインストールされます。

$ /opt/rh/rh-git218/root/usr/bin/git version
git version 2.18.4

PATH設定してリビルド

$ export PATH=/opt/rh/rh-git218/root/usr/bin:$PATH
$ ./build.sh v3.0.4
▶️ ./build.sh v3.0.4
/opt/rh/rh-git218/root/usr/libexec/git-core/git-remote-https: error while loading shared libraries: libcurl-httpd24.so.4: cannot open shared object file: No such file or directory
❌ Remote branch 'v3.0.4' not found in 'https://github.com/netbox-community/netbox.git'; Nothing to do

をしようとすると、更にエラー。
検索すると以下がヒット。

bugzilla.redhat.com

$ sudo ln -s /opt/rh/httpd24/root/usr/lib64/libcurl-httpd24.so.4 /lib64/

この状態で更にリビルトしようとすると、同じように以下のエラー

$ ./build.sh v3.0.4
▶️ ./build.sh v3.0.4
/opt/rh/rh-git218/root/usr/libexec/git-core/git-remote-https: error while loading shared libraries: libnghttp2-httpd24.so.14: cannot open shared object file: No such file or directory
❌ Remote branch 'v3.0.4' not found in 'https://github.com/netbox-community/netbox.git'; Nothing to do

これも同様に、

$ sudo ln -s /opt/rh/httpd24/root/usr/lib64/libnghttp2-httpd24.so.14 /lib64/

する。
今度こそリビルド。

$ ./build.sh v3.0.4

しばらく待てばビルド完了するはず。

$ docker image ls
REPOSITORY               TAG           IMAGE ID       CREATED              SIZE
netboxcommunity/netbox   latest-ldap   feae491462bb   41 seconds ago       442MB
netboxcommunity/netbox   v3.0-ldap     feae491462bb   41 seconds ago       442MB
netboxcommunity/netbox   v3.0.4-ldap   feae491462bb   41 seconds ago       442MB
netboxcommunity/netbox   latest        b746cc1f2603   About a minute ago   436MB
netboxcommunity/netbox   v3.0          b746cc1f2603   About a minute ago   436MB
netboxcommunity/netbox   v3.0.4        b746cc1f2603   About a minute ago   436MB

[...]

あとは同じようにdocker-compose.override.ymlを作成し、docker compose up -dでデプロイできます。

$ docker compose up -d
[+] Running 1/3
 ⠴ redis-cache Pulling                                                                                          1.6s
   ⠿ 552d1f2373af Already exists                                                                                0.0s
   ⠋ 08b93f529d04 Waiting                                                                                       0.1s
[+] Running 1/169 Waiting                                                                                       0.1s
 ⠦ redis-cache Pulling                                                                                          1.7s

[...]

現状だとHTTPアクセスになっており経路が暗号化されないのでその点は注意。
あくまでお試しということで、セキュリティグループで自分のIPアドレスでのみアクセスできるようにするなどフィルタした方がよい。

Docker PluginとしてDocker Compose (v2) のインストールとお試し実行 (arm64 / Oracle Cloud A1.Flex)

気が付いたらCompose v2がリリース版になってました。

github.com

これまでのようにdocker-composeコマンド単体でなく、Docker Pluginとして利用する形式になっています。
あとv1系のときはx86_64のバイナリしかなかったけど、arm64やs390xのバイナリも配布されるようになってるようです。
Linuxの場合は現状ではマニュアルインストールとなっており、必要なバイナリを所定のパスにダウンロードして利用します。

バイナリはReleaseページから。

github.com

インストール手順はDockerのドキュメント参照。 ただし、2021.9.29時点でまだバージョンがv2.0.0-rc.3になっているのでここをv2.0.0に置き換えて、アーキテクチャも環境に合わせる。今回はarm64で。

docs.docker.com

Dockerがインストールされてる状態で以下実行(arm64の場合)。

$ mkdir -p ~/.docker/cli-plugins/
$ curl -SL https://github.com/docker/compose/releases/download/v2.0.0/docker-compose-linux-arm64 -o ~/.docker/cli-plugins/docker-compose
$ chmod +x ~/.docker/cli-plugins/docker-compose

これでdocker composeが実行できるようになります。(docker-composeでなく)

$ docker compose version
Docker Compose version v2.0.0

サンプル用Composeファイルは以下の通り。

$ cat docker-compose.yml 
version: '3'
services:
  httpd:
    image: httpd
    ports:
    - 8080:80
$ docker compose up -d
[+] Running 6/6
 ⠿ httpd Pulled                                                                      4.9s
   ⠿ 896f18f54b28 Pull complete                                                      2.1s
   ⠿ 678f4022827b Pull complete                                                      2.9s
   ⠿ c18c6f886b61 Pull complete                                                      3.2s
   ⠿ 8f8bb463f1da Pull complete                                                      4.4s
   ⠿ 5590d606630f Pull complete                                                      4.5s
[+] Running 2/2
 ⠿ Network compose_default    Created                                                0.2s
 ⠿ Container compose-httpd-1  Started                                                0.6s
$ docker compose ps
NAME                COMMAND              SERVICE             STATUS              PORTS
compose-httpd-1     "httpd-foreground"   httpd               running             0.0.0.0:8080->80/tcp, :::8080->80/tcp

Oracle CloudのA1.FlexコンピュートインスタンスOracle Linux 8とUbuntu20.04で確認。
どちらも同じ手順で実行確認。

つい先日arm64向けバイナリがないということでpipを使ってインストールしたけど、v2がリリースバージョンになってるしこっちでよいかな。

zaki-hmkc.hatenablog.com

[Oracle Cloud/A1.Flex] armアーキテクチャのLinuxへpipでDocker Composeインストール

Oracle CloudのA1.Flexのように、aarch64/arm64のアーキテクチャへのDocker本体のインストールは以下のとおり公式の手順で(ディストリビューションが対応してれば)インストールできる。

zaki-hmkc.hatenablog.com

ただし、Docker Composeについては公式で配布されてるバイナリはamd64しかないため、公式の手順通りにインストールしてもarm64上のホストだと実行できない (※ 9/29追記: Docker Compose v2になってarm64版も公開されるようになっており、Docker Pluginとして利用可能) 。

github.com

「Cloud Integrations」とされてるこちらのComposeだとarm64版も配布されてて試した限り動かせそうだけど、コマンド体系が微妙に違う?(詳細よくわからず)

github.com

使い慣れてるのDocker Composeをarm64のホストにインストールするには、pipでインストールするのが簡単そうだったので試してみた。

docs.docker.com

ドキュメントの「Install Compose」->「Alternative install options」->「Install using pip」を参照。 公式ではvirtualenv推奨となってるけど本エントリではとりあえずsudoでシステムワイドに入れてる。

環境はOracle Cloudの無償枠A1.FlexVMを使用。

Ubuntu 20.04

pipはデフォルトでは入ってないのでaptでインストールする。

$ sudo apt-get install python3-pip
$ sudo pip install docker-compose

sudoつけてpipで入れると/usr/local/bin/docker-composeにインストールされる。
venvで環境分けた場合に以下のエラーが出るのであれば、venv作成時に--system-site-packagesつけておけばよいかも。

  error: invalid command 'bdist_wheel'
  ----------------------------------------
  ERROR: Failed building wheel for docopt
$ docker-compose version
docker-compose version 1.29.2, build unknown
docker-py version: 5.0.2
CPython version: 3.8.10
OpenSSL version: OpenSSL 1.1.1f  31 Mar 2020

サンプル実行。Compose Fileはこんな感じ。

version: '3'
services:
  httpd:
    image: httpd
    ports:
    - 8080:80
$ docker-compose up -d
Creating network "compose_default" with the default driver
Pulling httpd (httpd:)...
latest: Pulling from library/httpd
d10c227306ce: Pull complete
11d295310975: Pull complete
0bd1854e47c1: Pull complete
f7ee7d85565b: Pull complete
6f13eaecb486: Pull complete
Digest: sha256:ead5178e79caa09343750bb03ff98e87ed57c537f2ae12685beb3a573cce8f55
Status: Downloaded newer image for httpd:latest
Creating compose_httpd_1 ... done
$ docker-compose ps
     Name             Command        State                  Ports                
---------------------------------------------------------------------------------
compose_httpd_1   httpd-foreground   Up      0.0.0.0:8080->80/tcp,:::8080->80/tcp
$ curl localhost:8080
<html><body><h1>It works!</h1></body></html>

Oracle Linux 8/7.9

Oracle Linuxの場合は8も7.9も手順は同じ。
pip3は始めから使用できる。

$ sudo pip3 install docker-compose

次のエラーが出る場合は…

Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-_2zf4o3l/pynacl/
Building wheels for collected packages: pynacl, pyrsistent
  Building wheel for pynacl (PEP 517) ... error
  build/temp.linux-aarch64-3.6/_sodium.c:22:12: fatal error: pyconfig.h: No such file or directory
   #  include <pyconfig.h>
              ^~~~~~~~~~~~
  compilation terminated.
  error: command 'gcc' failed with exit status 1
  ----------------------------------------
  ERROR: Failed building wheel for pynacl

この場合はdevel系のパッケージを追加して再度pipインストールする。

$ sudo dnf install python3-devel

インストールできればこの通り。サンプルはUbuntuの時と同じもの。

$ docker-compose up -d
Creating network "compose_default" with the default driver
Pulling httpd (httpd:)...
latest: Pulling from library/httpd
d10c227306ce: Pull complete
11d295310975: Pull complete
0bd1854e47c1: Pull complete
f7ee7d85565b: Pull complete
6f13eaecb486: Pull complete
Digest: sha256:ead5178e79caa09343750bb03ff98e87ed57c537f2ae12685beb3a573cce8f55
Status: Downloaded newer image for httpd:latest
Creating compose_httpd_1 ... done
$ curl localhost:8080
<html><body><h1>It works!</h1></body></html>

[Oracle Cloud] 無料枠のA1.FlexのコンピュートインスタンスにDockerインストール (Ubuntu/Oracle Linux)

少し前に比べると、最大で4CPUs・RAM24GBまで無料で使用できるA1.Flexのコンピュートインスタンス(VM)を作成しやすくなったのでお試し。
結論から言うとVMのイメージはUbuntuであれば問題なし。
Oracle Linuxの場合はデフォルトの7.9より8の方が手間は無い。ただし、Docker公式はOracle Linux用のパッケージは用意されてないのでここで紹介してる手順は一応動くよというレベルで当然無保証。

あとアーキテクチャは普段よく使用されているamd64でなくarm64になるので、使いたいイメージによっては公開されてないこともあるので注意。(Docker Hubのイメージ検索の「OS/ARCH」のところにlinux/arm/v*のあるイメージであればデプロイ可能)

Ubuntu

特に問題無し。公式の手順通りでインストールできる。

docs.docker.com

$ uname -a
Linux opc-ubu-a1 5.11.0-1016-oracle #17~20.04.1-Ubuntu SMP Thu Aug 12 06:20:07 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.3 LTS"
$ sudo apt-get update
$ sudo apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg \
    lsb-release
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

stableリポジトリの追加は、arm64用の設定を行う。

$ echo \
  "deb [arch=arm64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

インストール

$ sudo apt-get update
$ sudo apt-get install docker-ce docker-ce-cli containerd.io
$ sudo docker version
Client: Docker Engine - Community
 Version:           20.10.8
 API version:       1.41
 Go version:        go1.16.6
 Git commit:        3967b7d
 Built:             Fri Jul 30 19:55:05 2021
 OS/Arch:           linux/arm64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.8
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.6
  Git commit:       75249d8
  Built:            Fri Jul 30 19:53:13 2021
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.4.9
  GitCommit:        e25210fe30a0a703442421b0f60afac609f950a3
 runc:
  Version:          1.0.1
  GitCommit:        v1.0.1-0-g4144b63
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

実行

$ sudo docker run --rm hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
109db8fad215: Pull complete 
Digest: sha256:61bd3cb6014296e214ff4c6407a5a7e7092dfa8eefdbbec539e133e97f63e09f
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (arm64v8)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

Oracle Linux

Oracle Linux用のパッケージは用意されてないので、お互いRHEL互換ということでCentOS用の手順でお試し(したら動いた、というもの)。
インストールおよびざっくり動かした感じではこれで大丈夫そう。(無保証)

docs.docker.com

以前(1.13?)はOracle Linux用(ver 6, 7)のインストール手順もあったっぽいけど、現在(2021.09時点)は無いみたい。

ver 8

Oracle Linux 8の場合はCentOS用の手順そのままでOK.

$ uname -a
Linux opc-ol8-a1 5.4.17-2102.204.4.4.el8uek.aarch64 #2 SMP Tue Aug 17 20:32:12 PDT 2021 aarch64 aarch64 aarch64 GNU/Linux
$ cat /etc/oracle-release 
Oracle Linux Server release 8.4
$ sudo yum install -y yum-utils
$ sudo yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo
$ sudo yum install docker-ce docker-ce-cli containerd.io

Ubuntuと異なり、インストールしただけだとサービスは有効にならないので有効化する。

$ systemctl status docker
● docker.service - Docker Application Container Engine
   Loaded: loaded (/usr/lib/systemd/system/docker.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
     Docs: https://docs.docker.com
$ sudo systemctl enable --now docker
$ sudo docker version
Client: Docker Engine - Community
 Version:           20.10.8
 API version:       1.41
 Go version:        go1.16.6
 Git commit:        3967b7d
 Built:             Fri Jul 30 19:54:06 2021
 OS/Arch:           linux/arm64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.8
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.6
  Git commit:       75249d8
  Built:            Fri Jul 30 19:52:39 2021
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.4.9
  GitCommit:        e25210fe30a0a703442421b0f60afac609f950a3
 runc:
  Version:          1.0.1
  GitCommit:        v1.0.1-0-g4144b63
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

実行

$ sudo docker run --rm hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
109db8fad215: Pull complete 
Digest: sha256:61bd3cb6014296e214ff4c6407a5a7e7092dfa8eefdbbec539e133e97f63e09f
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (arm64v8)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

ver 7.9

7.9(OCIでコンピュートインスタンス作るときはこれがデフォルトになってる)の場合は、これもCentOS用の手順通りでインストールできるけど、Dockerが依存するパッケージのインストールがデフォルトだとリポジトリが無効になってて失敗するので、これを追加するための1手順が必要。

$ uname -a
Linux opc-ol7-a1 5.4.17-2102.204.4.4.el7uek.aarch64 #2 SMP Wed Aug 18 11:37:16 PDT 2021 aarch64 aarch64 aarch64 GNU/Linux
$ cat /etc/oracle-release 
Oracle Linux Server release 7.9
$ sudo yum install -y yum-utils
$ sudo yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo
$ sudo yum install docker-ce docker-ce-cli containerd.io

[...]

エラー: パッケージ: docker-ce-rootless-extras-20.10.8-3.el7.aarch64 (docker-ce-stable)
             要求: fuse-overlayfs >= 0.7
エラー: パッケージ: docker-ce-rootless-extras-20.10.8-3.el7.aarch64 (docker-ce-stable)
             要求: slirp4netns >= 0.4
 問題を回避するために --skip-broken を用いることができます。
 これらを試行できます: rpm -Va --nofiles --nodigest

VM作成直後の状態だと、fuse-overlayfsslirp4netnsについて依存関係を解決できずこのようにエラーになる。

yum.oracle.com

この2つのパッケージは、ol7_developer リポジトリに含まれるので、リポジトリを有効にすればOK.

$ sudo yum-config-manager --enable ol7_developer

これでsudo yum install docker-ce docker-ce-cli containerd.ioでインストールできるようになる。

[...]

インストール:
  containerd.io.aarch64 0:1.4.9-3.1.el7             docker-ce.aarch64 3:20.10.8-3.el7             docker-ce-cli.aarch64 1:20.10.8-3.el7            

依存性関連をインストールしました:
  container-selinux.noarch 2:2.119.2-1.911c772.el7_8   docker-ce-rootless-extras.aarch64 0:20.10.8-3.el7   fuse-overlayfs.aarch64 0:0.7.2-6.el7_8  
  fuse3-libs.aarch64 0:3.6.1-4.el7                     slirp4netns.aarch64 0:0.4.3-4.el7_8                

完了しました!

あとはver8の場合と同じ。

$ sudo systemctl enable --now docker
$ sudo docker version
Client: Docker Engine - Community
 Version:           20.10.8
 API version:       1.41
 Go version:        go1.16.6
 Git commit:        3967b7d
 Built:             Fri Jul 30 19:55:48 2021
 OS/Arch:           linux/arm64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.8
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.6
  Git commit:       75249d8
  Built:            Fri Jul 30 19:54:18 2021
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.4.9
  GitCommit:        e25210fe30a0a703442421b0f60afac609f950a3
 runc:
  Version:          1.0.1
  GitCommit:        v1.0.1-0-g4144b63
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

実行

$ sudo docker run --rm hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
109db8fad215: Pull complete 
Digest: sha256:61bd3cb6014296e214ff4c6407a5a7e7092dfa8eefdbbec539e133e97f63e09f
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (arm64v8)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

ほかにも、デフォルトのリポジトリだとGitのクライアントバージョンも1系なので、今ならもうOracle Linux使うなら7.9より8の方が良いのかな?


CPUアーキテクチャとかあまりちゃんと理解できてないので間違ったこと書いてたらすみません。