Go to Qiita Advent Calendar 2024 Top
LoginSignup
18
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

OpenShiftAdvent Calendar 2019

Day 4
@zaki-lknrin株式会社エーピーコミュニケーションズ

【OpenShift 4】CodeReady Containers 1.2.0をWindowsで動かそうとしたら大変だった話

Last updated at Posted at 2019-12-03

本記事はOpenShift Advent Calendar 2019の4日目のエントリになります。
仕事でOpenShift(3.11)のインストールばかり1年以上やっていますが結構しんどい(笑)です。
(GitOpsとかCI/CDとかクラウドネイティブなアプリ開発とか色々やってみたい…！)

実は初めてのアドベントカレンダー参加ですがよろしくお願いします。

2020.09.23追記:
ver1.16(OCP ver 4.5.9)で試すと、本記事内の「あらかじめcrcという名前で仮想スイッチを作っておく」必要が無くなり、"Default Switch"でデプロイできるようになった模様。(正確には、本記事作成時に"crc"に名前変更したスイッチを、また別の名前にして試してもうまくいった)
また、DNSに関してもOS設定が変更されないようになり、stop後もそのまま使えるようになっています。(どこでCRC用DNS設定を参照しているのか不明…)

個人環境で無料で利用できるOpenShift 4.x環境4選 - zaki work log

TL;DR

実を言うとVirtualBoxはもうだめです。突然こんなこと言ってごめんね。でも本当です。もうしばらくするとクリスマスになります。それが終わりの合図です。

というわけで、WindowsにCodeReady Containersをセットアップするにはv1.2.0時点ではHyper-Vほぼ一択。
ただしそれでもv1.2.0ではcrcという名前で仮想スイッチを事前準備する必要があったり、まだ他のプラットフォーム程お手軽セットアップはできない。
ちなみに古いバージョン(2019年12月時点でのv1.1.0以前など)のCodeReady Containersは、証明書の期限が切れているためデプロイできない。

環境があるならLinuxにデプロイするのがトラブルが少ないです💦
macOSは環境持ってないので試せず…すみません。(なんとなくWindowsよりはトラブル少ない感じはしますが)

CodeReady Containersとは

(以下、個人の解釈が入り混じっています)

OpenShift version 4をシングルノードVM環境にデプロイするツールです。
Kubernetesユーザであれば、Minikubeというシングルノード環境をデプロイするツールがありますが、あれのOpenShift 4版だと思っていただいて大丈夫なはずです。
MinikubeのようなことをするOpenShift用ツールは、以前はMinishiftがあったのですが(いや、今もあるけど)、小耳に挟んだ情報では3.11で対応が終了してしまったらしいです。
4.x以降はCodeReady Containersを使うようになりました。

code-ready/crc: CodeReady Containers is a tool that manages a local OpenShift 4.x cluster optimized for testing and development purposes

MinikubeやMinishiftを使ったことある方ならイメージ付きやすいですが、導入したホストOS上で動作する仮想環境(libvirt/HyperKit/Hyper-V)を使ってVMを作成し、そのVMをノードとしてOpenShift 4をデプロイします。

図にするとこんな感じ。

crc.png

ただ、Minikube/Minishiftと違って、主に以下の違いがあります。

  • プロファイル切り替えによる複数クラスタ管理ができない
  • ノードへの(minikube sshのようなわかりやすい)ssh接続機能がない
  • DNS設定が別途必要

ちなみに、似た名前のツールにCodeReady Workspacesというものがあります。
これはコンテナで動作するEclipse Cheをベースにオーケストレーション環境で動作するIDEです。
が、CodeReady Containersとは関係ないっぽいです。
うーむ、なぜこんな紛らわしいネーミングになったのだろう…

システム要件

1.3. Minimum system requirements

HW要件に以下の通り記載があります。

項目 要件
vCPU 4
memory 8GB
storage 35GB

これ、ホストOSのスペックだと勘違いしそうだけど(というか、私は勘違いした)、実は「OpenShift 4をデプロイするためのCodeReady Containersが作成するVMのHW要件」になってます。
つまりこのスペックのVMが仮想環境に作成されるので、ホストOSのHW要件は推して知るべし。

インストール

基本的な インストールの流れを説明します。
といっても、公式のドキュメント通りに進めれば特に難しいことはないです。
Windowsの場合はv1.2.0だとドキュメントの通りでは足りないため、一手間二手間加える必要があります(後述)。

以上で基本的にOKです。

Linuxであれば、これで動きます。
また、CodeReady Containersへアクセスするための名前解決の設定もCodeReady Containersが(DNS入れてくれたりして)やってくれます。

Hyper-V環境へのインストール

本記事の本題です。

実はv1.0.0のときにVirtualBoxへのインストールは(だいぶ苦労したけど)実現してて、Hyper-Vは公式サポートしてるから楽勝だろうと高を括ってて、本当は「Windows環境へのCodeReady ContainersはちょっとコツがあるけどこうすればHyper-VもVirtualBoxもできるぜっ！！！」という記事にしたかったのですが、いろいろ制限多すぎて挫折しかけました。

Hyper-Vへのインストールはv1.2.0はなんとか成功したので、その手順について説明します。

以下、システム要件(スペック＆バージョン: Fall Creators Update (version 1709))は満たしているものとします。

準備

基本と同じです。

  • crc-windows-amd64.zip
  • pull-secret.txt

crc-windows-amd64.zipを展開し、環境変数PATHの設定をします。

PS C:\Users\zaki> crc version
crc version: 1.2.0+c2e3c0f
OpenShift version: 4.2.8 (embedded in binary)
PS C:\Users\zaki>

バージョンが出力されればOKです。

また、ipconfig /allなどで、DNSサーバの設定を控えておいてください。

crc setup

crc setupを実行します。

PS C:\Users\zaki> crc setup
INFO Checking if running as normal user
INFO Caching oc binary
INFO Unpacking bundle from the CRC binary
INFO Check Windows 10 release
INFO Hyper-V installed
INFO Is user a member of the Hyper-V Administrators group
ERRO User is not a member of the Hyper-V administrators group
INFO Will run as admin: add user to hyperv admins group
INFO Does the Hyper-V virtual switch exist
ERRO Virtual Switch not found
ERRO Unable to perform Hyper-V administrative commands. Please make sure to re-login or reboot your system
FATA Unable to perform Hyper-V administrative commands. Please make sure to re-login or reboot your system
PS C:\Users\zaki>

しかしv1.2.0ではドキュメントの通りに何度やってもこのエラーになります。
crc setupを実行しているユーザがHyper-V Adminitratorグループに含まれていてもこのエラーになります。

2019-11-28_08h16_02.png

メッセージを見る限り、CodeReady Containersで使用するVirtual Switchが無いという状態だけど、実はソースコードを確認すると、「Virtual Switchが無い場合は作成する」というロジックが現状まだ存在しません。

preflight_checks_windows.go
// Unable to do for now
func fixHyperVVirtualSwitch() (bool, error) {
    return false, errors.New("Unable to perform Hyper-V administrative commands. Please make sure to re-login or reboot your system")
}

ではどうすれば良いかと言うと話は単純で、必要なVirtual Switchをあらかじめ作っておけばOKです。
では必要なVirtual Switchが何かというと、ここのcheckIfHyperVVirtualSwitchExists()というチェック関数から参照している、hyperv.AlternativeNetworkにあるcrcという名前のVirtual Switchがあればよいです。

constants_windows.go
package hyperv

const (
    // Alternative
    AlternativeNetwork = "crc"
)

Hyper-VのVirtual Switchはちょっと複雑(と個人的に思い込んでる)なので、「新規で追加」するのがいろいろ設定が面倒な場合は、既存の通信可能なVirtual Switchの「名前」を変更してもOK (手元の環境ではそれで動作した)
手元の環境では、Hyper-V導入時に自動で作成されるoutbound-vswitchをcrcに名称変更すれば大丈夫でした。

image.png

これで、crc setupは「crcというVirtual SwitchがあるのでOK」という動作をします。

PS C:\Users\zaki> crc setup --log-level debug
INFO Checking if running as normal user
INFO Caching oc binary
DEBU oc binary already cached
INFO Unpacking bundle from the CRC binary
INFO Check Windows 10 release
INFO Hyper-V installed
INFO Is user a member of the Hyper-V Administrators group
INFO Does the Hyper-V virtual switch exist
INFO Found Virtual Switch to use: crc
Setup is complete, you can now run 'crc start' to start the OpenShift cluster
PS C:\Users\zaki>

crc start

繰り返しますが、crc start前に、DNS設定を控えておいてください。
DNS設定をメモったらcrc startします。

PS C:\Users\zaki> crc start --pull-secret-file .\Downloads\pull-secret.txt
INFO Checking if running as normal user
INFO Checking if oc binary is cached
INFO Check Windows 10 release
INFO Hyper-V installed and operational
INFO Is user a member of the Hyper-V Administrators group
INFO Does the Hyper-V virtual switch exist
INFO Found Virtual Switch to use: crc
INFO Extracting bundle: crc_hyperv_4.2.8.crcbundle ...
INFO Creating CodeReady Containers VM for OpenShift 4.2.8...
INFO Verifying validity of the cluster certificates ...
INFO Will run as admin: add dns server address to interface vEthernet (crc)
INFO Check internal and public DNS query ...
INFO Copying kubeconfig file to instance dir ...
INFO Adding user's pull secret and cluster ID ...
INFO Starting OpenShift cluster ... [waiting 3m]
INFO
INFO To access the cluster, first set up your environment by following 'crc oc-env' instructions
INFO Then you can access it by running 'oc login -u developer -p developer https://api.crc.testing:6443'
INFO To login as an admin, username is 'kubeadmin' and password is *****-*****-*****-*****
INFO
INFO You can now run 'crc console' and use these credentials to access the OpenShift web console
Started the OpenShift cluster
WARN The cluster might report a degraded or error state. This is expected since several operators have been disabled to lower the resource usage. For more information, please consult the documentation
PS C:\Users\zaki>

何事もなく成功しました。

oc loginするには、出力にある通りoc login -u developer -p developer https://api.crc.testing:6443すれば通常ユーザでログインできます。
cluster-adminが必要であれば、kubeadminユーザでパスワードも記載されている通りの内容でoc loginできます。

Extracting bundle: crc_hyperv_4.2.8.crcbundleはかなり時間かかります。
また、Will run as admin: add dns server address to interface vEthernet (crc)は特権が必要なのでUACのダイアログで実行を許可する操作が必要。

--pull-secret-file .\Downloads\pull-secret.txtは、pull secretのファイルをダウンロードしていた場合に指定します。
指定しない場合は処理中にsecretの値を聞いてくるので、[Copy Pull Secret]でクリップボードにsecretの内容をコピーし、それを貼り付けてもOK。

image.png

DNS設定

crc start処理内の特権を使って何をしているかと言うと、Windowsのネットワーク設定のDNSサーバーのアドレスを、CodeReady Containersで作成するノードのアドレスに設定します。

図にするとこんな感じ

crc on Hyper-V DNS設定.png

ノードの中はdnsmasqが稼働しており、ホストOSに元々設定されていたDNSサーバを上位DNSとして設定して動作しています。

これでOpenShift ClusterへのコンソールやpodへのワイルドカードDNSが必要なアクセスの名前解決ができるようになります。

ただこれ、CodeReady Containersを停止しても自動では元に戻りません。
なのでcrc stopで停止するとDNSサーバーが居なくなる状態になるため、手動で元に戻す必要があります。

再度crc startすれば、DNSサーバー設定はまたCodeReady Containersのノードになります。

ちなみにLinuxの場合は、ホストOS上にdnsmasqがインストールされ、必要なゾーン設定が行われます。

あとはcrc oc-envでocコマンドの場所を確認し、OpenShiftを使い倒せばOKです。

VirtualBox環境へのインストール

本記事のおまけです。

VirtualBoxへのインストールはv1.2.0で実質不可能になりました。
リソースはまだ提供されてますが、crcコマンドでVirtualBox用のロジックが消え始めており、v1.2.0では動作しなくなっています。
以下、なぜ動かないのかざっくり調べました。

また、現時点(2019年12月上旬のCodeReady Containers v1.2.0リリース済みの今)で、VirtualBoxへ 無理やり OpenShiftクラスタをデプロイする手順について(アドカレ公開前日の朝に回避策を思いついてしまったので)説明します。

インストールに使用するcrc-windows-amd64.zipはHyper-Vの場合と同じです。
ただし追加でVirtualBox用のcrcbundleファイルが必要です。これはサーバーのファイル一覧から直接ダウンロードします。
(その他のプラットフォームの場合はcrc setupの処理内でダウンロードされます)

Index of /pub/openshift-v4/clients/crc/1.2.0

crc setup --vm-driver virtualboxが失敗する

合っているはずのコマンド実行。

PS C:\Users\zaki> crc setup  --vm-driver virtualbox --log-level debug
INFO Checking if running as normal user
INFO Caching oc binary
DEBU oc binary already cached
INFO Unpacking bundle from the CRC binary
DEBU CreateFile C:\Users\zaki\.crc\cache\crc_hyperv_4.2.8.crcbundle: The system cannot find the file specified.
INFO Check Windows 10 release
INFO Hyper-V installed
ERRO Hyper-V not installed
DEBU Hyper-V not installed
INFO Will run as admin: enable Hyper-V
ERRO Please reboot your system
INFO Is user a member of the Hyper-V Administrators group
ERRO User is not a member of the Hyper-V administrators group
DEBU User is not a member of the Hyper-V administrators group
DEBU exit status 1
ERRO Unable to get group name
FATA Unable to get group name
PS C:\Users\zaki>

--vm-driver virtualboxを指定しているのにHyper-Vとして処理されてしまう。なぜ。(ログレベルを見てもわからない)

ちなみにv1.0.0のcrcで実行した場合…

PS C:\Users\zaki> C:\local\crc-windows-1.0.0-amd64\crc.exe setup -d virtualbox --log-level debug
INFO Checking if running as normal user
INFO Caching oc binary
DEBU oc binary is not cached
DEBU Downloading oc
DEBU Downloading https://mirror.openshift.com/pub/openshift-v4/clients/oc/latest/windows/oc.zip to C:\Users\zaki\AppData\Local\Temp\crc871007279
DEBU Download saved to C:\Users\zaki\AppData\Local\Temp\crc871007279\oc.zip
DEBU Uncompressing C:\Users\zaki\AppData\Local\Temp\crc871007279\oc.zip to C:\Users\zaki\AppData\Local\Temp\crc871007279
DEBU Copying 'C:\Users\zaki\AppData\Local\Temp\crc871007279\oc.exe' to 'C:\Users\zaki\.crc\bin\oc.exe'
DEBU oc binary cached
INFO Unpacking bundle from the CRC binary
DEBU FindFirstFile C:\Users\zaki\.crc\crc_hyperv_4.2.0.crcbundle: The system cannot find the file specified.
Setup is complete, you can now run 'crc start' to start the OpenShift cluster
PS C:\Users\zaki>

ですよね。
v1.2.0ではvirtualboxというパラメタが無視されている？

なぜHyper-Vとして処理されるのか

virtualboxの処理を探す

というわけで、Windowsに関するドキュメントほぼ見当たらないので、ソースを当たってみます。
まずはvirtualboxをキーに検索してみると…

crc/driver_windows.go at v1.2.0 · code-ready/crc

driver_windows.go
    // Supported drivers
    switch machineConfig.VMDriver {

    case "virtualbox":
        logging.Warn("Virtualbox support is deprecated and will be removed in the next release.")
        driver = virtualbox.CreateHost(machineConfig)
    case "hyperv":
        driver = hyperv.CreateHost(machineConfig)

    default:
        errors.ExitWithMessage(1, "Unsupported driver: %s", machineConfig.VMDriver)
    }

はい、どうやら次のバージョンではVirtualBoxは削除されるようです。
Remove Virtualbox support (deprecated) · Issue #838 · code-ready/crc

ん、でも、じゃあ現在のv1.2.0ではなぜ動かない？

crc/client_windows.go at v1.2.0 · code-ready/crc

client_windows.go
        switch driverName {
        case "virtualbox":
            plugin.RegisterDriver(virtualbox.NewDriver("", ""))
        case "hyperv":
            plugin.RegisterDriver(hyperv.NewDriver("", ""))
        default:
            errors.ExitWithMessage(1, fmt.Sprintf("Unregistered driver: %s\n", driverName))
        }

この辺は定義は残っている。

crc/driver.go at v1.2.0 · code-ready/crc

driver.go
func CreateHost(machineConfig config.MachineConfig) *virtualbox.Driver {
    virtualboxDriver := virtualbox.NewDriver(machineConfig.Name, constants.MachineBaseDir)

    virtualboxDriver.CPU = machineConfig.CPUs
    virtualboxDriver.BundleName = machineConfig.BundleName
    virtualboxDriver.Memory = machineConfig.Memory

    // Network
    virtualboxDriver.HostOnlyCIDR = "192.168.130.1/24"

//[snip]

VirtualBoxを指定した場合のホスト作成のパラメタあたり。この辺も大丈夫そう。(たぶんこのソースが無くなるのかな？)

これらの呼び出し元もざっと検索した限りでは「もしvirtualboxだったら処理しない」という感じにはなっていなかった。
はっはっは、全くわからない。(Goちからが絶望的に不足している)

setupの処理を見ていく

virtualboxの場合の処理を探しても見つからなさそうなので、crc setupの処理を見ていく。

ひとまず定義されてないドライバ名を指定。(もしかしてパラメタに関係なくhypervとして扱われてたりする？)

PS C:\Users\zaki> crc setup -d zzz --log-level debug
ERRO Unsupported driver: zzz, use '--vm-driver' option to provide a supported driver [hyperv virtualbox]
PS C:\Users\zaki>

んなこたーない。ちゃんとチェックされてる。
ということは、強制的にhypervとして処理されている？

setupのコマンドのソースから見てみよう。
crc/setup.go at v1.2.0 · code-ready/crc

setup.go
func runSetup(arguments []string) {
    if err := validateSetupFlags(); err != nil {
        errors.Exit(1)
    }

まずはvalidation処理があります。
すぐ下に定義してあるvalidateSetupFlags()をコールしてる。

setup.go
func validateSetupFlags() error {
    if err := validation.ValidateDriver(vmDriver); err != nil {
        return err
    }
    return nil
}

長くなるので省略するけど、「Windowsの場合はhypervかvirtualboxの場合」以外を弾くようになっているので、「virtualboxの場合も問答無用でhypervにしちゃう」みたいなコードはさすがになかった。

その次の処理

setup.go
    preflight.SetupHost()

結論としてはここだった。

crc/preflight_windows.go at v1.2.0 · code-ready/crc
このWindowsの場合のソースなんだけど、Hyper-Vの処理は実装されてるけど、VirtualBoxの場合の処理はない。
この処理がvirtualboxの場合も呼ばれているため、Hyper-Vの処理に失敗してエラーとなってしまう。

v1.1.0のときのソースを見ればすぐわかるけど、以前は「hypervの場合のみ処理する」というロジックになっていた。
この変更によって、常にHyper-Vの場合の処理が行われるようになった模様。

Remove all VirtualBox preflight checks from our codebase · Issue #662 · code-ready/crc

うーん、残念。
まぁもともとWindowsでの利用はHyper-Vをサポートだったからなぁ。。

ということで、VirtualBoxでどうしてもという場合(Windows 10 homeとか)、v1.1.0で一応動くかと思いきや、v1.1.0は証明書の期限の問題で動作しない。

v1.1.0のインストールを試してみる(失敗した手順)

以下のことを試してみたけどダメでした。

やったこと 結果
普通にv1.1.0インストール 2019.11.30で証明書期限切れ(VMは起動するがOCPは起動しない)
ホストOS/BIOSの日付を11/29にしてv1.1.0インストール VM内の日付は騙せなかったせいかある程度起動するが同様に起動失敗(6443/TCPのAPIサーバは起動する等かなり良いところまで行くが、route podのhaproxyが起動しないためoc loginをはじめあらゆるアクセスが通らない)

ちょっとゴニョゴニョする程度ではやっぱり使用できないようです。
おそらく、virtualbox指定の場合はHyper-Vの処理をスキップするように修正したcrcのソースをリビルドすれば動作すると思う。(未確認)

v1.1.0のcrcでv1.2.0のcrcbundleを入れてみる(成功編)

思いつく限り、現在(2019.12上旬)VirtualBoxへCodeReady Containersを入れるには、(crcの修正版リビルドを行う以外には)これしかないかも。
そして証明書の期限を考えると、クリスマス頃までの期間限定手順。(それ以降は自分であらゆるバイナリを用意する必要がありそう)

当然ながら無保証です。
大まかな流れは以下の通り。

  1. crcはv1.1.0、crcbundleは最新のv1.2.0を用意
  2. crcbundleのファイル名を、v1.1.0に対応した4.2.2にリネーム(v1.2.0だと4.2.8)
  3. 展開されたVMのパスも4.2.2にリネーム
  4. sshの秘密鍵を入れ替える
  5. ノードOSのIPアドレスをhostsファイルに設定

これで起動します。
また、作業をスムーズに行うために、ターミナルは2つ(crc setup|start実行用と、鍵設定とcrc ip実行用)起動しておき、名前解決用のhostsファイルをすぐ編集できるようにエディタで開いておきます。

以下、具体的な作業手順。

crc version

PS C:\Users\zaki> crc version
crc version: 1.1.0+95966a9
OpenShift version: 4.2.2 (embedded in binary)
PS C:\Users\zaki>

crc setup

PS C:\Users\zaki> crc setup --vm-driver virtualbox --log-level debug
INFO Checking if running as normal user
INFO Caching oc binary
DEBU oc binary is not cached
DEBU Downloading oc
DEBU Downloading https://mirror.openshift.com/pub/openshift-v4/clients/oc/latest/windows/oc.zip to C:\Users\zaki\AppData\Local\Temp\crc191759951
DEBU Download saved to C:\Users\zaki\AppData\Local\Temp\crc191759951\oc.zip
DEBU Uncompressing C:\Users\zaki\AppData\Local\Temp\crc191759951\oc.zip to C:\Users\zaki\AppData\Local\Temp\crc191759951
DEBU Copying 'C:\Users\zaki\AppData\Local\Temp\crc191759951\oc.exe' to 'C:\Users\zaki\.crc\bin\oc.exe'
DEBU oc binary cached
INFO Unpacking bundle from the CRC binary
DEBU CreateFile C:\Users\zaki\.crc\crc_hyperv_4.2.2.crcbundle: The system cannot find the file specified.
Setup is complete, you can now run 'crc start' to start the OpenShift cluster
PS C:\Users\zaki>

ここまでは普通です。

crc start

v1.2.0用のcrc_virtualbox_4.2.8.crcbundleを4.2.2にリネームして--bundleで指定してcrc start実行します。(4.2.8のまま実行するとエラーになる)

PS C:\Users\zaki> crc start --vm-driver virtualbox --bundle .\archives\crc\1.2.0\crc_virtualbox_4.2.2.crcbundle --pull-secret-file .\archives\crc\pull-secret.txt
WARN A new version (1.2.0) has been published on https://cloud.redhat.com/openshift/install/crc/installer-provisioned
INFO Checking if running as normal user
INFO Checking if oc binary is cached
INFO Extracting bundle: crc_virtualbox_4.2.2.crcbundle ...
ERRO Error getting bundle metadata: Could not find cached bundle info

ただし、これもエラーになります。
というのも、ファイルの実体が4.2.8なcrcbundleはファイルを展開するとパスも4.2.8になるため。

PS C:\Users\zaki> ls .\.crc\cache\

    ディレクトリ: C:\Users\zaki\.crc\cache

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----       2019/12/03     23:21                crc_virtualbox_4.2.8

PS C:\Users\zaki>

これもディレクトリ名も4.2.8から4.2.2にリネームしてやります。

PS C:\Users\zaki> mv .\.crc\cache\crc_virtualbox_4.2.8\ .\.crc\cache\crc_virtualbox_4.2.2
PS C:\Users\zaki> ls .\.crc\cache\

    ディレクトリ: C:\Users\zaki\.crc\cache

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----       2019/12/03     23:21                crc_virtualbox_4.2.2

PS C:\Users\zaki>

これで、再度crc startを実行。
ただしここでもコツが要ります。

PS C:\Users\zaki> crc start --vm-driver virtualbox --bundle .\archives\crc\1.2.0\crc_virtualbox_4.2.2.crcbundle --pull-secret-file .\archives\crc\pull-secret.txt
WARN A new version (1.2.0) has been published on https://cloud.redhat.com/openshift/install/crc/installer-provisioned
INFO Checking if running as normal user
INFO Checking if oc binary is cached
INFO Loading bundle: crc_virtualbox_4.2.2.crcbundle ...
INFO Creating CodeReady Containers VM for OpenShift 4.2.8...
INFO Verifying validity of the cluster certificates ...
Please follow instructions in the documentation about setting hostnames for Virtualbox.
INFO Check internal and public DNS query ...
INFO Copying kubeconfig file to instance dir ...
INFO Adding user's pull secret and cluster ID ...

この辺までログが出力されたら、以下の鍵入れ替えとhosts設定を すみやかに 行います。

ssh秘密鍵入れ替え

[BUG] CRC failed to restart when use virtualbox · Issue #691 · code-ready/crc

この不具合があるため、VirtualBoxでのCodeReady Containers利用はssh秘密鍵の入れ替えを手動で行う必要があります。(ステータスがclosedになってるけど、解決済みじゃなくてサポート終了っぽい…)

入れ替えと言っても、単に.crc\machines\crc\id_rsaにある秘密鍵のファイルを.crc\cache\crc_virtualbox_4.2.2\id_rsa_crcへコピー＆リネームしてやればOKです。
コマンド的にはホームディレクトリにいる状態で以下の2つを連続で実行すればOK。

  • mv .\.crc\cache\crc_virtualbox_4.2.2\id_rsa_crc .\.crc\cache\crc_virtualbox_4.2.2\id_rsa_crc.bak
  • cp .\.crc\machines\crc\id_rsa .\.crc\cache\crc_virtualbox_4.2.2\id_rsa_crc
PS C:\Users\zaki> mv .\.crc\cache\crc_virtualbox_4.2.2\id_rsa_crc .\.crc\cache\crc_virtualbox_4.2.2\id_rsa_crc.bak
PS C:\Users\zaki> cp .\.crc\machines\crc\id_rsa .\.crc\cache\crc_virtualbox_4.2.2\id_rsa_crc

hosts設定

Hyper-Vのノードと違って、VirtualBoxのノードでは、ホストOSのDNS設定をVMのアドレスにしても、名前解決はしてくれませんでした。
なので、hostsを使って名前解決の設定をしてやります。

hostsに最低限加える内容は以下の通り。

hosts
192.168.130.100 api.crc.testing oauth-openshift.apps-crc.testing console-openshift-console.apps-crc.testing

ホスト名はそれぞれ

  • api.crc.testing: APIサーバ
  • oauth-openshift.apps-crc.testing: 認証するときにアクセスするサーバ
  • console-openshift-console.apps-crc.testing: webコンソール

ocでCLI操作する場合も、oauthのサーバへアクセスできる必要がある。(oc loginの際にアクセス)

入力するIPアドレスは、crc ipを実行すれば確認できます。

PS C:\Users\zaki> crc ip
192.168.130.100

起動時は最低限これだけあれば大丈夫。
クラスタ構築後、podを作成してoc exposeとかしていく場合、都度ホスト名を追加してください。
基本はoc get route -AのHOST/PORTのホスト名一覧を全部書いておけば良いです。(面倒だけど)

crc start続き

ssh鍵入れ替えとhosts設定の内容がうまいこと処理されれば、インストールが進むはずです。
全体としてはこんな感じになるはず。

PS C:\Users\zaki> crc start --vm-driver virtualbox --bundle .\archives\crc\1.2.0\crc_virtualbox_4.2.2.crcbundle --pull-secret-file .\archives\crc\pull-secret.txt
WARN A new version (1.2.0) has been published on https://cloud.redhat.com/openshift/install/crc/installer-provisioned
INFO Checking if running as normal user
INFO Checking if oc binary is cached
INFO Loading bundle: crc_virtualbox_4.2.2.crcbundle ...
INFO Creating CodeReady Containers VM for OpenShift 4.2.8...
INFO Verifying validity of the cluster certificates ...
Please follow instructions in the documentation about setting hostnames for Virtualbox.
INFO Check internal and public DNS query ...
INFO Copying kubeconfig file to instance dir ...
INFO Adding user's pull secret and cluster ID ...
INFO Starting OpenShift cluster ... [waiting 3m]
INFO
INFO To access the cluster, first set up your environment by following 'crc oc-env' instructions
INFO Then you can access it by running 'oc login -u developer -p developer https://api.crc.testing:6443'
INFO To login as an admin, username is 'kubeadmin' and password is *****-*****-*****-*****
INFO
INFO You can now run 'crc console' and use these credentials to access the OpenShift web console
Started the OpenShift cluster
WARN The cluster might report a degraded or error state. This is expected since several operators have been disabled to lower the resource usage. For more information, please consult the documentation
PS C:\Users\zaki>

これでcrc consoleすればブラウザでwebコンソールが起動します。
ocも普通に動く。

oc loginはHyper-Vの章に書いた内容と同じく、出力にある通りoc login -u developer -p developer https://api.crc.testing:6443で通常ユーザでログイン、cluster-adminが必要であればkubeadminユーザで記載されているパスワードの内容でoc loginすればOKです。

Tipsや制限など

ノードOSへssh

3.2. Getting shell access to the OpenShift cluster より。

(host os)$ oc get node
(host os)$ oc debug nodes/$(node-name)
(pod)# chroot /host

する。

PS C:\Users\zaki> oc get node
NAME                 STATUS   ROLES           AGE   VERSION
crc-2n9vw-master-0   Ready    master,worker   9d    v1.14.6+6ac6aa4b0
PS C:\Users\zaki> oc debug nodes/crc-2n9vw-master-0
Starting pod/crc-2n9vw-master-0-debug ...
To use host binaries, run `chroot /host`
Pod IP: 192.168.0.52
If you don't see a command prompt, try pressing enter.
sh-4.2#
sh-4.2# chroot /host
sh-4.4# hostname
crc-2n9vw-master-0
sh-4.4#
sh-4.4# uname -a
Linux crc-2n9vw-master-0 4.18.0-147.0.3.el8_1.x86_64 #1 SMP Mon Nov 11 12:58:36 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
sh-4.4# echo $SHELL
/bin/bash
sh-4.4# cat /etc/redhat-release
Red Hat Enterprise Linux CoreOS release 4.2
sh-4.4#

こんな感じ。

ちなみに、sshで直接入ることもできる。

  1. crc ipでノードのIPアドレスを確認
  2. ノードアクセス用のssh秘密鍵は~/.crc/machines/crc/id_rsaにある
  3. ノードOS上のユーザ名はcore(固定)

Vagrantのsshアクセスでゴニョゴニョしたことあれば手順はピンとくるはず。

PS C:\Users\zaki> crc ip
192.168.0.52
PS C:\Users\zaki> ssh -i .\.crc\machines\crc\id_rsa core@192.168.0.52
Red Hat Enterprise Linux CoreOS 42.81.20191119.1
WARNING: Direct SSH access to machines is not recommended.

---
Last login: Mon Dec  2 11:51:05 2019 from 192.168.0.10
[core@crc-2n9vw-master-0 ~]$

Direct SSH access to machines is not recommended

と出ているので、そのつもりで。

とはいえ、VMは起動してるのにOpenShiftクラスタは起動してない場合とか、いろいろ調査が必要な時にアクセスしてみると、OSを直で見れるので良いかも。(ss -anptでLISTENしてるのか？とか)

ちなみに、VMのOSってFedora CoreOSだろうと思ってたんだけど、RHCOSなのね。

証明書30日制限

ドキュメントにはv1.2.0以降は自動更新とある。
しばらく様子を見よう。。

古いCodeReady Containersを使っていて証明書期限が切れてる場合は、残念ながら一度crc deleteして再度セットアップしましょう。

11/27にv1.0.0-rcを起動

1か月半ぶりくらいに1.0.0-rcをcrc startしたら「Certs have expired, they were valid till: 28 Oct 19 10:58 +0000 」だって…

2019-11-27_20h48_20.png

同じく11/27にv1.0.0を起動

Certs have expired, they were valid till: 16 Nov 19 05:02 +0000

2019-11-27_21h01_46.png

サーバー上のタイムスタンプを見る限り、1.0.0-rc0は9/29に、1.0.0は10/19にリリースされている。

バージョン リリース日 expire
1.2.0-4.2.8 11/26 🎄？
1.1.0-4.2.2 11/1 11/30
1.0.0-4.2.0 10/19 11/16
1.0.0-rc.0-4.2.0-0.nightly 9/28 10/28

証明書の30日サイクルがあるということは、次バージョンのリリース日もある程度予測できるってことなのかな。

さいごに

何だかんだでクライアントPCはWindowsという方、それなりにいらっしゃると思います。(いるよね？)
v1.2.0の時点ではまだセットアップに苦労しますが、これからもっと簡単に使えるようになっていくと思います。
何はともあれ、WindowsでCodeReady Containersを使ったOpenShift 4デプロイ、ちょっと苦労あって環境も選びますが、手元で動かせるのは何かと便利です。

とはいえ……Dockerだってそのまま使えるし、Linux使っておくほうが無難かもしれない(あ、言っちゃった)

VirtualBoxは、、、残念ですね……

お知らせなど

18
8
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
18
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?