連投やで ども。レッドハットでストレージを中心にクラウドインフラを生業にしている宇都宮です。 この業界の恒例となった12月のアドベントカレンダーですが、なんとRookもアドベントカレンダーをやります！Special thanks to tzkobaさん！ qiita.com Rook勢では知らない人は居ないであろう tzkoba さん、makotowさん ががっつり書きますよ！ 僭越ながら宇都宮も12/1から8連投で投げさせていただきます！肩ちぎれるまで根性で投げますよ！12月はRook MeetupもあるしOpenShift.RUNもあるしなんかすごいぞ！アハハ！ 引き続き、RookとOpenShift Japan CommunityのTwitterアカウント、 @japan_rook と @openshiftjp のフォローお願いしまーす！ Ceph Dashboard はい、てなわけで 前回 はCephFSを使ってみました。今回はCeph Dashboardを使ってみましょう。 CephはKraken(v11)から"ceph-mgr"というdaemonが登場しました。ceph-mgrはceph-monを補助するように、監視機能を提供したり外部の監視ツール/ソフトウェアのサービスと連携したりする役割を担います。ceph-mgrはLuminous(v12)からceph-monとセットでデプロイされるようになっていて、標準でCephクラスタの利用状況をGUIで表示するDashboardが搭載されています。 もちろんRook-Cephでもceph-mgrはデプロイされるのでDashboardは利用できます。今日はそれをちょっと使ってみましょう。 Dashboardを有効にする Kubernetesの環境は 前回 と同じものをそのまま使います。 kubectl create -f operator.yaml までは前回と同じでいいですが、 kubectl create -f cluster.yaml のところ、つまりCephクラスタを作るところで一回止まりましょう。 Ceph Dashboardを使うためには、まずCephクラスタのマニフェストファイル(cluster.yaml)の中で、dashboardをenableに設定する必要があります。デフォルトで enabled: true になっているので、意図的にfalseにしてない限り変更する必要はないでしょう。 ちなみにコメントアウトされてるパラメータを設定することでポートやURLを編集できます。 [utubo@tutsunom ceph]$ grep -A 7 "dashboard:" cluster.yaml dashboard: enabled: true # serve the dashboard under a subpath (useful when you are accessing the dashboard via a reverse proxy) # urlPrefix: /ceph-dashboard # serve the dashboard at the given port. # port: 8443 # serve the dashboard using SSL ssl: true 念の為CephClusterリソースでもチェックして、Serviceも確認しておきましょう。 [utubo@tutsunom ceph]$ kubectl describe cephcluster|grep -A 2 Dashboard Dashboard: Enabled: true Ssl: true [utubo@tutsunom ceph]$ kubectl get svc rook-ceph-mgr-dashboard NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE rook-ceph-mgr-dashboard ClusterIP 100.70.46.106 <none> 8443/TCP 3d10h はい、大丈夫ですね。 Dashboardを外部に公開する Ceph Dashboardのサービスを外部に公開します。方法はNodePortでもLoadBalancerでもIngressでも、全て設定するyamlがあるので好きなのでいいと思います。ここでは一番楽チンなLoadBalancerでいきます。 [utubo@tutsunom ceph]$ ls -l dashboard-* -rw-rw-r-- 1 utubo utubo 362 11月 21 21:14 dashboard-external-http.yaml -rw-rw-r-- 1 utubo utubo 363 11月 21 21:14 dashboard-external-https.yaml -rw-rw-r-- 1 utubo utubo 839 11月 21 21:14 dashboard-ingress-https.yaml -rw-rw-r-- 1 utubo utubo 365 11月 21 21:14 dashboard-loadbalancer.yaml [utubo@tutsunom ceph]$ [utubo@tutsunom ceph]$ cat dashboard-loadbalancer.yaml apiVersion: v1 kind: Service metadata: name: rook-ceph-mgr-dashboard-loadbalancer namespace: rook-ceph labels: app: rook-ceph-mgr rook_cluster: rook-ceph spec: ports: - name: dashboard port: 8443 protocol: TCP targetPort: 8443 selector: app: rook-ceph-mgr rook_cluster: rook-ceph sessionAffinity: None type: LoadBalancer [utubo@tutsunom ceph]$ [utubo@tutsunom ceph]$ kubectl create -f dashboard-loadbalancer.yaml service/rook-ceph-mgr-dashboard-loadbalancer created [utubo@tutsunom ceph]$ [utubo@tutsunom ceph]$ kubectl get svc -l app=rook-ceph-mgr NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE rook-ceph-mgr ClusterIP 100.70.230.202 <none> 9283/TCP 3d10h rook-ceph-mgr-dashboard ClusterIP 100.70.46.106 <none> 8443/TCP 3d10h rook-ceph-mgr-dashboard-loadbalancer LoadBalancer 100.65.39.6 xxxx7c64cbfaa4e71949f59d4c10687c-1467982743.us-east-1.elb.amazonaws.com 8443:31564/TCP 39s できた。あとはWebブラウザからEXTERNAL-IPに表示されてるURLに8443番ポートでアクセスすると見られます。 Dashboardに接続する そしたら公開されたDashboardに接続してみましょう。 ストイックでカッコイイ。 イエーイ。 さっそくログインしたいところですが、usernameとpasswordは何を使えばいいんでしょうか。 DashboardをenableにしてCephクラスタを作ると、Rookはデフォルトのdashboardユーザーである admin と、そのSecretである rook-ceph-dashboard-admin-password を作成します。このSecretからadminのパスワードを調べればいいです。パスワードは普通に kubectl get で見えますが、表示される文字列はbase64でエンコードされてるのでデコードするように注意しましょう。 [utubo@tutsunom ceph]$ kubectl get secret rook-ceph-dashboard-password -o jsonpath="{['data']['password']}" | base64 --decode && echo XXXXXXXXXX 10文字のpasswordが出てくるので、これを使ってDashboardにログインします。 箱に文字。分かりやすい。 ログインしたらこんな感じでステータスやらCephクラスタの構成やらの一覧がバンと表示されます。上の方のメニュー選んでいくとクラスタのパラメータ値とか割と事細かく情報が見ることができて、結構使えると思います。 意外とグラフィカル。小学X年生の付録にあった立体メガネを思い出す。 Cephクラスタを視認性高くモニタリングすることができるのが、Ceph Dashboardです。 まとめ 今回はサクッとCeph Dashboardの紹介をしてみました。 今回はデフォルトのadminユーザーを使いましたが、もちろん他のユーザーを作れます。Dashboardのユーザーアクセス制御はRBACで、情報ごとにCRUDの権限を設定してRoleを作成できるので、一般ユーザーさんに公開することもできます。 はい、というわけで今日はここまで。

まいど。レッドハットでストレージを中心にクラウドインフラを生業にしている宇都宮です。 Red Hat Forum Tokyoの準備にかまけてすっかり間があいてしまいました(汗) 去る11/15にRed Hat Forum Tokyoがありました。足を運んでくださった皆さん、ありがとうございました。 今年のForumではROOK CHALLENGEという展示ブースの一角を担当させていただきました。中身はほぼDIY工作だったのでめっちゃ疲れましたが、めっちゃ楽しかったです。とにかく目立つ異様な一角を提供できたかなーと思います。 ROOK CHALLENGEは12/09開催予定の Japan Rook Meetup#1 と、12/20開催予定の OpenShift.RUN の両方で展示する予定です。 引き続き、RookとOpenShift Japan CommunityのTwitterアカウント、 @japan_rook と @openshiftjp のフォローお願いしまーす！ 前回 はRook-Ceph CSIのアーキテクチャのお話でした。今回はこのCeph CSIドライバを使ってCephFSを使ってみましょうね。 CephFSってなによ はいそれでは本題に入ります。Cephは本体部分がRADOSというオブジェクトストアなんですが、ファイルアクセスのインターフェースを持ってます。それをCephFSと呼んだりします。 ファイルアクセスのインターフェースと言っても、Linux kernelが持ってるクライアントか、独自のFUSEクライアントを使ってマウントします。一般的なNFSやCIFSのようなファイルプロトコルでクライアントからマウントすることはできません。(Cephの上にNFS serverやSambaが稼働するサーバーを置いて、いわゆるNAS GatewayのようにすることでNFS,CIFSに対応することは可能) そんなCephFSですが、もちろんRook-Ceph上でも使うことができます。RWXのPVが必要な時はCephFS使うことになるので、使い方を覚えておくと便利ですよ。 KubernetesクラスタとCephクラスタの作成 いつもどおりAWS上に3master+6workerで作って、3workerをストレージ専用に使います。3workerに role=app , 3workerは role=storage とlabelを付けます。ストレージ専用のworkerには、それぞれ20GBのEBSを1つずつattachしておきます。 [utubo@tutsunom ceph]$ kubectl get node --sort-by=".metadata.creationTimestamp" -L role NAME STATUS ROLES AGE VERSION ROLE ip-172-20-55-215.ec2.internal Ready master 2d18h v1.15.5 ip-172-20-123-190.ec2.internal Ready master 2d18h v1.15.5 ip-172-20-87-105.ec2.internal Ready master 2d18h v1.15.5 ip-172-20-58-75.ec2.internal Ready node 2d18h v1.15.5 app ip-172-20-106-226.ec2.internal Ready node 2d18h v1.15.5 app ip-172-20-90-59.ec2.internal Ready node 2d18h v1.15.5 app ip-172-20-76-87.ec2.internal Ready node 12m v1.15.5 storage ip-172-20-102-73.ec2.internal Ready node 12m v1.15.5 storage ip-172-20-44-151.ec2.internal Ready node 12m v1.15.5 storage 次はRook-Ceph operatorでCephクラスタを作ります。 何気にこれまで、githubのrookリポジトリをcloneしてやるスタンダードな方法を紹介してなかったので、今回は簡単にやりますね。 [utubo@tutsunom ~]$ git clone -b release-1.1 https://github.com/rook/rook.git [utubo@tutsunom ~]$ cd rook/cluster/examples/kubernetes/ceph [utubo@tutsunom ceph]$ kubectl create -f common.yaml 好きなブランチでgit cloneしましょう。masterでもいいですがstableな方がいいでしょう。最新のstableなのは1.1なので、これを使います。 で、奥深く掘り進んで行って、 common.yaml を kubectl create します。ちょっと試すぶんにはこの辺は何も考えずにやっちゃっていいです。 はい、次に kubectl create -f operator.yaml でoperatorを入れます。 何も考えずにやっちゃってもいいんですが、そうするとappノードにもrook-discover podが上がってしまいます。 rook-discoverは、ノードにHDDやSSDみたいなデバイスがattachされたかどうかをずっと見張ってる奴です。今回デバイスはstorageノードにしか付けません。つまりappノードにrook-discoverが居ても意味がない。だからstorageノードにだけrook-discoverが上がるようにNodeAffinityを設定しておきます。元のoperator.yamlの中に、グレーアウトしてる DISCOVER_AGENT_NODE_AFFINITY というオプションがあるので、こいつをいじるのが話早いと思います。役に立つかもしれないので後段で使ったoperator.yamlを置いておきます。 https://gist.github.com/1be5a50b52a1cb293f8086199023abc7 [utubo@tutsunom ceph]$ kubectl create -f operator.yaml [utubo@tutsunom ceph]$ kubectl create -f cluster.yaml [utubo@tutsunom ceph]$ kubectl create -f toolbox.yaml はい、これで5,6分ほどコーヒーを飲んで待てばCephクラスタができてるはずです。 [utubo@tutsunom ceph]$ kubectl get pod NAME READY STATUS RESTARTS AGE csi-cephfsplugin-2chlm 3/3 Running 0 112m csi-cephfsplugin-7zm85 3/3 Running 0 112m csi-cephfsplugin-pjmrc 3/3 Running 0 112m csi-cephfsplugin-provisioner-7565878587-4v5zc 4/4 Running 0 112m csi-cephfsplugin-provisioner-7565878587-tq9vv 4/4 Running 0 112m csi-cephfsplugin-qwcxs 3/3 Running 0 112m csi-cephfsplugin-rmld5 3/3 Running 0 112m csi-cephfsplugin-tq5d7 3/3 Running 0 112m csi-rbdplugin-bfc9s 3/3 Running 0 112m csi-rbdplugin-dsvlg 3/3 Running 0 112m csi-rbdplugin-fd7dr 3/3 Running 0 112m csi-rbdplugin-jbblr 3/3 Running 0 112m csi-rbdplugin-provisioner-d6bf7b9d9-fk2qp 5/5 Running 0 112m csi-rbdplugin-provisioner-d6bf7b9d9-kl5vx 5/5 Running 0 112m csi-rbdplugin-twt8d 3/3 Running 0 112m csi-rbdplugin-vb4p5 3/3 Running 0 112m rook-ceph-mgr-a-69c747f894-9blsd 1/1 Running 0 111m rook-ceph-mon-a-5cf48c58b5-xg5zg 1/1 Running 0 112m rook-ceph-mon-b-5f7cb997bd-f9gjs 1/1 Running 0 112m rook-ceph-mon-c-7c4dbc56ff-fxrsz 1/1 Running 0 111m rook-ceph-operator-7fcd9b6cc9-jrjpg 1/1 Running 0 115m rook-ceph-osd-0-855d7c96c-n6pkw 1/1 Running 0 110m rook-ceph-osd-1-856d8b8f94-jgrxz 1/1 Running 0 110m rook-ceph-osd-2-657c4b68bc-vl5cn 1/1 Running 0 110m rook-ceph-osd-prepare-ip-172-20-102-73.ec2.internal-dwhgv 0/1 Completed 0 111m rook-ceph-osd-prepare-ip-172-20-106-226.ec2.internal-vzx9f 0/1 Completed 0 111m rook-ceph-osd-prepare-ip-172-20-44-151.ec2.internal-srsgj 0/1 Completed 0 111m rook-ceph-osd-prepare-ip-172-20-58-75.ec2.internal-ltnnx 0/1 Completed 0 111m rook-ceph-osd-prepare-ip-172-20-76-87.ec2.internal-4q8zf 0/1 Completed 0 111m rook-ceph-osd-prepare-ip-172-20-90-59.ec2.internal-n2mj8 0/1 Completed 0 111m rook-ceph-tools-5bc668d889-qcsw9 1/1 Running 0 110m rook-discover-26kcq 1/1 Running 0 115m rook-discover-fthtd 1/1 Running 0 115m rook-discover-h4glj 1/1 Running 0 115m [utubo@tutsunom ceph]$ kubectl exec -it `kubectl get pod -l app=rook-ceph-tools -o 'jsonpath={.items[].metadata.name}'` \ > ceph status cluster: id: a578ddea-9338-40ad-b50b-8acabfc6e8f1 health: HEALTH_OK services: mon: 3 daemons, quorum a,b,c (age 107s) mgr: a(active, since 75s) osd: 3 osds: 3 up (since 34s), 3 in (since 34s) data: pools: 0 pools, 0 pgs objects: 0 objects, 0 B usage: 3.0 GiB used, 54 GiB / 57 GiB avail pgs: はい、クラスタできてます。 CephFS ファイルシステムを作る それではCephでファイルシステムを作りましょう。簡単です。 [utubo@tutsunom ceph]$ kubectl create -f filesystem.yaml cephfilesystem.ceph.rook.io/myfs created これだけ。rook-ceph-mds-myfs-〜というpodが2つ上がってればオッケーです。 [utubo@tutsunom ceph]$ kubectl get pod -l app=rook-ceph-mds NAME READY STATUS RESTARTS AGE rook-ceph-mds-myfs-a-55574457b-xn5c7 1/1 Running 0 43m rook-ceph-mds-myfs-b-86cbb9f884-9mtsl 1/1 Running 0 43m オッケーね。Ceph側ではどう見えるでしょうか。 [utubo@tutsunom ceph]$ kubectl exec -it `kubectl get pod -l app=rook-ceph-tools -o 'jsonpath={.items[].metadata.name}'` \ > ceph fs ls name: myfs, metadata pool: myfs-metadata, data pools: [myfs-data0 ] [utubo@tutsunom ceph]$ [utubo@tutsunom ceph]$ kubectl exec -it `kubectl get pod -l app=rook-ceph-tools -o 'jsonpath={.items[].metadata.name}'` \ > ceph df RAW STORAGE: CLASS SIZE AVAIL USED RAW USED %RAW USED ssd 57 GiB 54 GiB 2.1 MiB 3.0 GiB 5.27 TOTAL 57 GiB 54 GiB 2.1 MiB 3.0 GiB 5.27 POOLS: POOL ID STORED OBJECTS USED %USED MAX AVAIL myfs-metadata 1 2.2 KiB 22 384 KiB 0 17 GiB myfs-data0 2 0 B 0 0 B 0 17 GiB Ceph側では、myfsというファイルシステムが1つできていて、myfs-metadataとmyfs-data0という2つのpoolができています。 先にも言った通り、CephはRADOSと呼ばれるオブジェクトストアが本体のデータ格納機構で、全てのデータをオブジェクトとして扱います。ファイルシステムとして利用する際には、ファイルの実体の他にメタデータも同じように保管しないといけません。 メタデータは参照される機会が多いし、ぶっ壊れたらファイルシステムそのものが使えなくなる可能性があります。なので実体よりも速くて冗長性が高いpoolに分ける方がオススメってことから、CephFSではファイルの実体とメタデータが別々のpoolに分けて保管されます。 ちなみに先にpodで上がってきたrook-ceph-mds〜の、"mds"は"metadata server"のことで、こいつがファイルのメタデータを扱います。CephFSを使う際にはceph-mdsは必須です。 アプリから使ってみる まずお約束のstorageclassの作成です。さらに深いセントラルドグマにマニフェストファイルがあります。 [utubo@tutsunom ceph]$ cd csi/cephfs/ [utubo@tutsunom cephfs]$ kubectl create -f csi/cephfs/storageclass.yaml storageclass.storage.k8s.io/csi-cephfs created [utubo@tutsunom cephfs]$ kubectl get sc NAME PROVISIONER AGE csi-cephfs rook-ceph.cephfs.csi.ceph.com 55s default kubernetes.io/aws-ebs 2d21h gp2 (default) kubernetes.io/aws-ebs 2d21h はいできた。名前が気に入らない場合は適宜変えてね！ さあここからだ。とりあえず第2話で現れたdateをひたすら吐き出すダメ MS appを改造して、3つのPodがappノードから同時に同じPVをRWXでマウントしdateを吐き出すappにしてみます。そう。ザクとは違うのだよ、ザ(略 [utubo@tutsunom cephfs]$ cat gouf.yaml apiVersion: apps/v1 kind: Deployment metadata: name: date spec: replicas: 3 selector: matchLabels: app: date strategy: type: Recreate template: metadata: labels: app: date spec: containers: - name: date image: busybox command: ["/bin/sh", "-c", "while true; do echo `date` by `hostname` >> /mnt/`hostname`; echo `date` by `hostname` >> /mnt/shared_file; sleep 1; done"] volumeMounts: - name: date-pv mountPath: "/mnt" volumes: - name: date-pv persistentVolumeClaim: claimName: cephfs-pvc affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: role operator: In values: - app --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: cephfs-pvc spec: accessModes: - ReadWriteMany resources: requests: storage: 1Gi storageClassName: csi-cephfs 初めにそれぞれのpodが、自分専用のファイル /mnt/`hostname` にdateを吐いて、次に共有のファイル /mnt/shared_file にdateを吐く感じにしました。それじゃあこのグフを走らせてみます。 [utubo@tutsunom cephfs]$ kubectl create -f gouf.yaml deployment.apps/date created persistentvolumeclaim/cephfs-pvc created [utubo@tutsunom cephfs]$ kubectl get pod,pvc,pv NAME READY STATUS RESTARTS AGE pod/date-55b84bcff-jvxfv 1/1 Running 0 24s pod/date-55b84bcff-mhclb 1/1 Running 0 24s pod/date-55b84bcff-tlcwp 1/1 Running 0 24s NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE persistentvolumeclaim/cephfs-pvc Bound pvc-f2b186f1-4947-46c4-9dd9-b6d3c86af3f0 1Gi RWX csi-cephfs 25s NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE persistentvolume/pvc-f2b186f1-4947-46c4-9dd9-b6d3c86af3f0 1Gi RWX Delete Bound default/cephfs-pvc csi-cephfs 23s よし。じゃあファイルの中身を見てみしょう。どれか1個のpodに入って見ます。 [utubo@tutsunom kubernetes]$ kubectl exec -it pod/date-55b84bcff-jvxfv sh / # ls -l /mnt total 10 -rw-r--r-- 1 root root 1802 Nov 22 06:46 date-55b84bcff-jvxfv -rw-r--r-- 1 root root 2014 Nov 22 06:46 date-55b84bcff-mhclb -rw-r--r-- 1 root root 1855 Nov 22 06:46 date-55b84bcff-tlcwp -rw-r--r-- 1 root root 3816 Nov 22 06:46 shared_file / # tail -n 5 /mnt/date-55b84bcff-jvxfv Fri Nov 22 06:47:07 UTC 2019 by date-55b84bcff-jvxfv Fri Nov 22 06:47:08 UTC 2019 by date-55b84bcff-jvxfv Fri Nov 22 06:47:09 UTC 2019 by date-55b84bcff-jvxfv Fri Nov 22 06:47:10 UTC 2019 by date-55b84bcff-jvxfv Fri Nov 22 06:47:11 UTC 2019 by date-55b84bcff-jvxfv / # tail -n 5 /mnt/date-55b84bcff-mhclb Fri Nov 22 06:47:17 UTC 2019 by date-55b84bcff-mhclb Fri Nov 22 06:47:18 UTC 2019 by date-55b84bcff-mhclb Fri Nov 22 06:47:19 UTC 2019 by date-55b84bcff-mhclb Fri Nov 22 06:47:20 UTC 2019 by date-55b84bcff-mhclb Fri Nov 22 06:47:21 UTC 2019 by date-55b84bcff-mhclb それぞれのpodのファイルには、それぞれのpodからしか書いてませんねー。(当たり前だ じゃあ共有のファイルは、 / # tail -f /mnt/shared_file Fri Nov 22 06:48:03 UTC 2019 by date-55b84bcff-tlcwp Fri Nov 22 06:48:04 UTC 2019 by date-55b84bcff-mhclb Fri Nov 22 06:48:04 UTC 2019 by date-55b84bcff-jvxfv Fri Nov 22 06:48:04 UTC 2019 by date-55b84bcff-tlcwp Fri Nov 22 06:48:05 UTC 2019 by date-55b84bcff-mhclb Fri Nov 22 06:48:05 UTC 2019 by date-55b84bcff-jvxfv Fri Nov 22 06:48:05 UTC 2019 by date-55b84bcff-tlcwp Fri Nov 22 06:48:06 UTC 2019 by date-55b84bcff-mhclb Fri Nov 22 06:48:06 UTC 2019 by date-55b84bcff-jvxfv Fri Nov 22 06:48:06 UTC 2019 by date-55b84bcff-tlcwp Fri Nov 22 06:48:07 UTC 2019 by date-55b84bcff-mhclb Fri Nov 22 06:48:07 UTC 2019 by date-55b84bcff-jvxfv Fri Nov 22 06:48:07 UTC 2019 by date-55b84bcff-tlcwp Fri Nov 22 06:48:08 UTC 2019 by date-55b84bcff-mhclb Fri Nov 22 06:48:08 UTC 2019 by date-55b84bcff-jvxfv Fri Nov 22 06:48:08 UTC 2019 by date-55b84bcff-tlcwp ... 3pod全員がdateを吐いてます。RWXだとこんな感じで同じファイルに書き込んだりできますね。もちろんファイルにロックが掛かってる時は書けないのでご注意ね☆ CephFSではPVはどう見える？ はい今日最後です。CephFSでPVはどういう風に扱われるのか確認してみましょう。先のグフでPVが1個切られましたが、もう1個PVCを投げて切ってみます。 [utubo@tutsunom cephfs]$ cat pvc.yaml --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: cephfs-pvc-2 spec: accessModes: - ReadWriteMany resources: requests: storage: 1Gi storageClassName: csi-cephfs [utubo@tutsunom cephfs]$ [utubo@tutsunom cephfs]$ kubectl create -f pvc.yaml persistentvolumeclaim/cephfs-pvc-2 created [utubo@tutsunom cephfs]$ kubectl get pvc,pv NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE persistentvolumeclaim/cephfs-pvc Bound pvc-f2b186f1-4947-46c4-9dd9-b6d3c86af3f0 1Gi RWX csi-cephfs 56m persistentvolumeclaim/cephfs-pvc-2 Bound pvc-2adef642-64ab-419a-b30c-abaa23fa7807 1Gi RWX csi-cephfs 46s NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE persistentvolume/pvc-2adef642-64ab-419a-b30c-abaa23fa7807 1Gi RWX Delete Bound default/cephfs-pvc-2 csi-cephfs 44s persistentvolume/pvc-f2b186f1-4947-46c4-9dd9-b6d3c86af3f0 1Gi RWX Delete Bound default/cephfs-pvc csi-cephfs 56m PVC,PVが2個ずつできました。Ceph側で確認してみましょう。 [utubo@tutsunom cephfs]$ kubectl -n rook-ceph exec -it `kubectl get pod -l app=rook-ceph-tools -o 'jsonpath={.items[].metadata.name}'` \ > ceph fs ls name: myfs, metadata pool: myfs-metadata, data pools: [myfs-data0 ] ファイルシステムは一つのままです。つまりCephFSでは、PVCごとに新しくファイルシステムが作られてPVとして出されるわけではないということですね。 ではPVはどこにあるのか、ファイルシステムを直でマウントして確認してみましょう。 ここ に書かれてる技を使えばtoolbox podにファイルシステムをマウントできるので、それにしたがってやってみます。 [utubo@tutsunom cephfs]$ kubectl -n rook-ceph exec -it `kubectl get pod -l app=rook-ceph-tools -o 'jsonpath={.items[].metadata.name}'` \ > sh sh-4.2# mkdir /tmp/cephfs sh-4.2# mon_endpoints=$(grep mon_host /etc/ceph/ceph.conf | awk '{print $3}') sh-4.2# my_secret=$(grep key /etc/ceph/keyring | awk '{print $3}') sh-4.2# mount -t ceph -o mds_namespace=myfs,name=admin,secret=$my_secret $mon_endpoints:/ /tmp/cephfs sh-4.2# df -h /tmp/cephfs Filesystem Size Used Avail Use% Mounted on 100.70.103.105:6789,100.65.186.42:6789,100.70.45.225:6789:/ 57G 3.3G 54G 6% /tmp/cephfs マウントできたっぽい。じゃあそのまま中身を見ていきましょう！ sh-4.2# cd /tmp/cephfs/ sh-4.2# ls -l total 0 drwxr-xr-x 1 root root 2 Nov 22 06:13 volumes sh-4.2# cd volumes/ ; ls -l total 0 drwx------ 1 root root 0 Nov 22 07:30 _deleting drwxr-xr-x 1 root root 2 Nov 22 07:30 csi sh-4.2# cd csi/ ; ls -l total 0 drwxrwxrwx 1 root root 4 Nov 22 06:34 csi-vol-18d47467-0cf2-11ea-895d-a6f6772013bd drwxrwxrwx 1 root root 0 Nov 22 07:30 csi-vol-efd2b71f-0cf9-11ea-895d-a6f6772013bd sh-4.2# cd csi-vol-18d47467-0cf2-11ea-895d-a6f6772013bd/ sh-4.2# ls -l total 1067 -rw-r--r-- 1 root root 198273 Nov 22 07:38 date-55b84bcff-jvxfv -rw-r--r-- 1 root root 199386 Nov 22 07:38 date-55b84bcff-mhclb -rw-r--r-- 1 root root 198750 Nov 22 07:38 date-55b84bcff-tlcwp -rw-r--r-- 1 root root 494755 Nov 22 07:38 shared_file sh-4.2# なるほど。Cephのファイルシステム的には、/filesystem_root/volumes/csi/csi-vol-xxx/ というディレクトリをPVとしてexportしていることがわかります。つまり、CephFSではデカいファイルシステムの中にサブディレクトリを切ってPVとしてユーザーに切り出すということですね。 まとめ はい、今日はRook 1.1を使ってRook-Ceph CSIでCephFSを使ってみました。CephFSってちょっと頼んないのかなって思ってたけど、意外と普通に使えるもんですね。それじゃあ今回はここまで。

Red Hatの福岡オフィスでソリューションアーキテクトをしている田中司恩です。 今回はOpenShift 4.2で追加された「ネットワークが制限された環境でのインストール」について説明します。 説明に使用する環境構成は以前に書いた記事と同様ですので、合わせてこちらもご参照ください。 rheb.hatenablog.com 本記事の章立てはこのようになります。 （2019/12/7追記。項目にOperatorの利用を追加） ネットワークが制限された環境でのインストール概要 検証環境解説 インストール手順解説 レジストリーホストの構築 UPIインストールの実行 アップグレード Operatorの利用 参考：Podmanコマンド ネットワークが制限された環境でのインストール概要 ネットワークが制限された環境は、英語ドキュメントではrestricted networkと表記されています。 他の呼び方として、DisconnectedやAir-gappedなどと呼ばれることもあります。 今回取り扱う内容においては、いずれもOpenShiftクラスターがインターネットへの通信ができない環境を指す、とご理解の上読み進めてください。 OpenShift 4はインストールの要件としてインターネットへの接続が必須となっています。 しかしながら、特にオンプレミスの環境では強固に制限されたネットワーク環境があることが多く、またそこへOpenShiftクラスターを展開したいという要望もあると思います。 今回ご紹介する方法により、OpneShiftクラスターをネットワークが制限された環境への導入が可能となります。 [図1] ネットワーク制限環境下のインストール 注意点としては、本来のOpenShift 4で提供できる下記のような機能が使えなくなることをご理解ください Over-The-Air Update cloud.redhat.comへのクラスターの自動登録、モニタリング（Telemetry） Operator HubからのOperatorインストール インターネットのソースやイメージを利用したデプロイ etc... 検証環境解説 インストール手順の説明の前に、今回の説明に使用する検証環境の説明を行います。 下記の図は4.1 UPIインストール記事からお馴染みの図となりますが、今回はネットワークの制限をより明確にしています。 また、ミラーされたイメージをホストするためのレジストリーホストを追加しています。 [図2] 検証環境ネットワーク構成図 ネットワークの通信可否は下記のようになっており、検証用ネットワークからは社内ネットワーク側には通信ができません。 社内ネットワーク：インターネット通信可能 検証用ネットワーク：インターネット通信不可 また、今回の構成においてOpenShiftクラスターへのアクセスは社内ネットワークからとし、片方向からのみのアクセスを許可する構成となっています。 [図3] ネットワーク通信詳細 踏み台サーバーのfirewalldは下記のように変更します。 # firewall-cmd --zone=block --add-rich-rule='rule family="ipv4" destination address="172.16.0.1/32" accept' --permanent # firewall-cmd --zone=block --add-rich-rule='rule family="ipv4" port port=67 protocol=udp accept' --permanent # firewall-cmd --change-zone=ens224 --zone=block --permanent # firewall-cmd --reload 検証用ネットワークからのDHCPパケットに応答するために UDP:67 のアクセスは許可 検証用ネットワークからの各種通信（DNS/Web/LB）に応答するために、 172.16.0.1/32 のアクセスは許可 インストール手順解説 今回もベアメタルへのUPIインストールをベースに説明していきます。 該当するドキュメントは下記です。 インストール 4.2 | Red Hat Customer Portal 第9章 ネットワークが制限されたインストール 9.1. 接続するネットワークが制限された環境でのインストール用のミラーレジストリーの作成 9.3. ネットワークが制限された環境でのクラスターのベアメタルへのインストール ※注意）公式ドキュメント上のbationホストは、本文中ではレジストリーホストを指します。 *1 また、下記のblog.openshift.com 記事も参考にし、ドキュメントに足りない情報を付け加えています。 blog.openshift.com 作業項目が多いので、まずは下記の作業サマリをご確認ください。 インストール作業サマリ レジストリーホストの構築 ミラーレジストリーの作成 ミラーレジストリーのプルシークレットの作成 イメージリポジトリーのミラーリング UPIインストールの実行（4.1/4.2 UPIと同様） インストール設定ファイルの手動作成（ネットワーク制限用設定を追加 ※新規設定 ） インストールの実行 インストール後の作業 エラー表示への対処 Samples Operatorの設定 Cluster Managerの登録 UPIインストール作業自体は4.1/4.2と同様ですが、前後に独自の作業が追加となっています。 次の項目からが実際の作業となります。 レジストリーホストの構築 基本的にはドキュメント通りの作業となります。必要最低限の前提条件は下記です。 前提条件 ocコマンドがインストールされていること（レジストリーホスト用のRHELサーバーが既にある前提） レジストリーホストのホスト名がDNSで名前解決できること 1. ミラーレジストリーの作成 ここでの作業の目的は、podmanコマンドを使って mirror-registry コンテナを起動することです。 また、コンテナ起動時に必要な証明書の作成も行います。 前提条件は下記の通りです。 前提条件 レジストリーホストとして使用する Red Hat Enterprise Linux (RHEL) サーバーがネットワーク上にある レジストリーホストはインターネットにアクセスできる。 今回はレジストリーホストにRHEL8を利用しています *2 1.1 作業に必要なパッケージをインストールします インストールパッケージ podman : レジストリーを実行する際に使用するコンテナーパッケージを提供します httpd-tools : ユーザーの作成に使用する htpasswd ユーティリティーを提供します # yum -y install podman httpd-tools 1.2 レジストリーのフォルダーを作成します。 # mkdir -p /opt/registry/{auth,certs,data} # tree /opt/registry/ /opt/registry/ ├── auth ├── certs └── data 3 directories, 0 files これらのフォルダーはレジストリーコンテナー内にマウントされます。 1.3 証明書を作成します 下記は自己署名の証明書生成の例です *3 # cd /opt/registry/certs # openssl req -newkey rsa:4096 -nodes -sha256 -keyout domain.key -x509 -days 365 -out domain.crt 下記は証明書作成時の情報入力のサンプルです。 Country Name (2 letter code) [XX]: JP State or Province Name (full name) : Fukuoka Locality Name (eg, city) [Default City]: Fukuoka Organization Name (eg, company) [Default Company Ltd]: [改行] Organizational Unit Name (eg, section) : [改行] Common Name (eg, your name or your server's hostname) : registry.test.example.local Email Address : [改行] ※ Common NameはFQDNで指定します 1.4 bcrpt 形式を使用するレジストリー用のユーザー名およびパスワードを生成します。 下記は、 /opt/registry/auth/htpasswd にユーザー名: user 、パスワード: user のユーザー作成例です。 # htpasswd -bBc /opt/registry/auth/htpasswd user user Adding password for user user 1.5 レジストリーに必要なポートを開きます ドキュメントの通りにinternalとpublicゾーンに設定を行うため、NICのゾーン変更も合わせて行います。 デフォルト状態からの設定変更についてのみ記載しています。不要なサービスなどは個々の環境に合わせて調整してください。 # firewall-cmd --add-port=5000/tcp --zone=internal --permanent # firewall-cmd --add-port=5000/tcp --zone=public --permanent # firewall-cmd --change-zone=ens224 --zone=internal --permanent # firewall-cmd --change-zone=ens192 --zone=public --permanent # firewall-cmd --reload ポートの開放後は下記のような状態になります internalゾーン # firewall-cmd --list-all --zone=internal internal (active) target: default icmp-block-inversion: no interfaces: ens224 sources: services: cockpit dhcpv6-client mdns samba-client ssh ports: 5000/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: publicゾーン # firewall-cmd --list-all --zone=public public (active) target: default icmp-block-inversion: no interfaces: ens192 sources: services: cockpit dhcpv6-client ssh ports: 5000/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: 1.6 信頼された証明書の一覧に自己署名証明書を追加します システム全体で使用されるトラストストアに作成した自己署名証明書を追加し、この後の作業で証明書が信頼された物として実行できるようにします。 *4 # cp /opt/registry/certs/domain.crt /etc/pki/ca-trust/source/anchors/ # update-ca-trust 1.7 レジストリーをホストする mirror-registry コンテナーを作成します。 ＜参考/注意＞ ここで指定するパラメーターに間違いや、環境不備などがあるとコンテナが正常に起動しません。 podmanコマンドを使用したコンテナの簡単な実行/リカバリー方法について記事末尾にまとめましたので、詳細はそちらを参照ください。 下記は待ち受けポートを tcp:5000 で指定し、コンテナをバックグラウンド起動するコマンド例です。 *5 この時点で docker.io からイメージをダウンロードするので、インターネットへアクセスができる必要があります。 # podman run --name mirror-registry -p 5000:5000 \ -v /opt/registry/data:/var/lib/registry:z \ -v /opt/registry/auth:/auth:z \ -e "REGISTRY_AUTH=htpasswd" \ -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \ -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \ -v /opt/registry/certs:/certs:z \ -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt \ -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key \ -d docker.io/library/registry:2 下記のコマンドを実行し てコンテナが正常に起動しているか確認します # podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES af99e9675c96 docker.io/library/registry:2 /entrypoint.sh /e... 5 seconds ago Up 5 seconds ago 0.0.0.0:5000->5000/tcp mirror-registry STATUS がUpで、 PORTS に指定したポート番号が表示されていることを確認します 1.8 レジストリーが使用できることを確認します 下記のコマンドを実行します。合わせてfirewallの設定を確認する場合は、別のホストから実行してください。 # curl -u user:user -k https://registry.test.example.local:5000/v2/_catalog 下記のように空のリポジトリの情報が表示されれば、正常にレジストリーコンテナが起動しています。　 {"repositories":[]} 2. ミラーレジストリーのプルシークレットの作成 ここでは、起動したレジストリーコンテナに登録したユーザー名/パスワードで接続を行い、プルシークレットを入手します。 使用するユーザー名/パスワードは、 1.4で作成した物を使用します。 # podman login --authfile ~/pullsecret_config.json registry.test.example.local:5000 Authenticating with existing credentials... Existing credentials are invalid, please enter valid username and password Username: user Password: Login Succeeded! 入手したプルシークレットの中身を確認します。 # cat ~/pullsecret_config.json { "auths": { "registry.test.example.local:5000": { "auth": "dXNlcjp1c2Vy" } } なお、 auth に指定されているパラメーターは、 ユーザー名:パスワード をbase64でエンコードした値になっています。 # echo -n 'user:user' | base64 -w0 dXNlcjp1c2Vy 2.1 追加作業 ドキュメントには記載されていませんが、追加で必要な作業を実施します。 *6 2.1.1 cloud.redhat.comからpull-secret.txtをダウンロード ブラウザで下記へアクセスし、 Download pull secret を選択 *7 https://cloud.redhat.com/openshift/install/metal/user-provisioned 2.1.2 プルシークレットのマージ 下記のコマンドを実行して、ミラーレジストリーから作成した物と cloud.redhat.com からダウンロードした物をマージします jqコマンドが無い場合は先にインストール # yum -y install jq 下記のコマンドを実行して、2つのプルシークレットをマージします # cd ~ # ls pull* pull-secret.txt pullsecret_config.json # jq -s '.[0] * .[1]' pullsecret_config.json pull-secret.txt > pull-secret-2.txt ※ ここから以降は、マージしたプルシークレット pull-secret-2.txt を使用します これ以降の手順では、ドキュメント上では一般ユーザーでの実行となっており、同様に行うためにプルシークレットを一般ユーザーディレクトリにコピーします。 # cp pull-secret-2.txt /home/user/ 3. イメージリポジトリーのミラーリング ここでは、インターネット上（quay.io）のインストールに必要なイメージをレジストリーホストにダウンロードします 前提条件 ミラーレジストリーを設定し、設定した証明書および認証情報にアクセスできること ミラーレジストリーおよび cloud.redhat.com から取得したプルシークレットをマージした物があること *8 3.1 ダウンロードバージョンの確認 下記のページを確認し、インストールする OpenShift Container Platform のバージョンを確認します https://access.redhat.com/downloads/content/290/ 3.2 環境変数を設定します $ export OCP_RELEASE='4.2.4' $ export LOCAL_REGISTRY='registry.test.example.local:5000' $ export LOCAL_REPOSITORY='ocp4/openshift4' $ export PRODUCT_REPO='openshift-release-dev' $ export LOCAL_SECRET_JSON='/home/user/pull-secret-2.txt' $ export RELEASE_NAME="ocp-release" 各パラメーター解説 OCP_RELEASE=' 4.2.4 ' # バージョンを指定 LOCAL_REGISTRY=' registry.test.example.local:5000 ' #絶対パス:ポート番号を指定 LOCAL_REPOSITORY=' ocp4/openshift4 ' # 任意。ここではドキュメント通り。 PRODUCT_REPO=' openshift-release-dev ' # 実稼働環境のリリースの場合には、openshift-release-devを指定する必要があり LOCAL_SECRET_JSON= '/home/user/pull-secret-2.txt' #マージしたプルシークレットを絶対パスで指定。 RELEASE_NAME=" ocp-release " # 実稼働環境のリリースについては、ocp-releaseを指定する必要があり 3.3 リポジトリのミラーリング実行 $ oc adm -a ${LOCAL_SECRET_JSON} release mirror \ --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE} \ --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \ --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE} ミラーリング成功時の結果 〜省略〜 Success Update image: registry.test.example.local:5000/ocp4/openshift4:4.2.4 Mirror prefix: registry.test.example.local:5000/ocp4/openshift4 To use the new mirrored repository to install, add the following section to the install-config.yaml: imageContentSources: - mirrors: - registry.test.example.local:5000/ocp4/openshift4 source: quay.io/openshift-release-dev/ocp-release - mirrors: - registry.test.example.local:5000/ocp4/openshift4 source: quay.io/openshift-release-dev/ocp-v4.0-art-dev 〜省略〜 3.4 imageContentSources セクションを記録 上記の結果に含まれる、 imageContentSources セクションを記録します。この情報は、この後のUPIインストールの設定ファイルの作成時に使用します。 3.5 インストールプログラムの作成 この手順は、ミラーしたイメージから openshift-install コマンドを入手する手順となります。 *9 $ oc adm release extract --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}" -a ${LOCAL_SECRET_JSON} $ ./openshift-install version ./openshift-install v4.2.4 built from commit 425e4ff0037487e32571258640b39f56d5ee5572 release image registry.test.example.local:5000/ocp4/openshift4@sha256:cebce35c054f1fb066a4dc0a518064945087ac1f3637fe23d2ee2b0c433d6ba8 oc コマンド入手時に openshift-install も入手されている場合はこの手順は不要です。 *10 参考 ドキュメントではこの後、 9.1.6. ネットワークが制限されたインストールでのイメージストリームサンプルの使用 という手順がありますが、実際にはこの手順はクラスターのインストール実行後に行う作業となります。 詳細は本記事の、 インストール後の設定 Samples Operatorの設定 を参照ください。 UPIインストールの実行 UPIインストール方法自体は4.1 UPIインストールと同様です。 本記事では追加となる作業についてのみ記載します。 インストール設定ファイルの手動作成 該当するドキュメントは下記の章になります。 第9章 ネットワークが制限されたインストール 9.3.6. インストール設定ファイルの手動作成 ここでは、インストール設定ファイル install-config.yaml を作成しますが、その中にミラーレジストリーの情報を追加します。 install-config.yaml apiVersion: v1 baseDomain: example.local compute: - hyperthreading: Enabled name: worker replicas: 0 controlPlane: hyperthreading: Enabled name: master replicas: 3 metadata: name: test networking: clusterNetworks: - cidr: 10.128.0.0/14 hostPrefix: 23 networkType: OpenShiftSDN serviceNetwork: - 172.30.0.0/16 platform: none: {} pullSecret: '{"auths":{"registry.test.example.local:5000":{"auth":"dXNlcjp1c2Vy"}}}' sshKey: 'ssh-rsa AAAA...' additionalTrustBundle: | -----BEGIN CERTIFICATE----- 〜省略〜 -----END CERTIFICATE----- pullSecret: にはミラーレジストリーから入手したプルシークレットの内容を記載します 。 下記のjqコマンドを使うとプルシークレットの内容を一行で表示できます。 $ jq -c . ~/pullsecret_config.json {"auths":{"registry.test.example.local:5000":{"auth":"dXNlcjp1c2Vy"}}} additionalTrustBundle: には作成した自己署名証明書の内容を記載します。証明書の内容は下記のコマンドで確認できます。 $ cat /etc/pki/ca-trust/source/anchors/domain.crt -----BEGIN CERTIFICATE----- 〜省略〜 -----END CERTIFICATE----- ※注意 ： install-config.yaml に証明書の内容を記載する際は、各行頭にスペースを追加してインデントしてください インストールの実行 install-config.yaml 作成後の手順は通常と同じです。4.1 UPIインストールの手順を参考にしてください。 インストール後の作業 エラー表示への対処 インストール後、ダッシュボードおよびMonitoring/Alertingに、 TelemeterClientDown のアラートが表示されます。 クラスターからインターネットへの接続が制限されているためにこのエラーが発生しています。 今回の構成において、クラスターのグローバルクラスタープルシークレットはミラーレジストリーから入手した内容になっていますので、事実上Telemetry機能は無効です。 3.3. リモートヘルスレポートのオプトアウト 4.2 | Red Hat Customer Portal この状態でもアラートは表示され続けるため、アラートをサイレンスに設定します。 Monitoring > Alerting > Alertタブで、TelemeterClientDownのSilence Alertを選択します。 [図4] Silence Alert Silence Alertの詳細入力画面になったら、StartとEndの期間を指定し、必要に応じてCreator/Commentを記入してCreateを選択します。 [図5] Silence Alert詳細入力画面 その後、TelemeterClientDownのStateがSilencedに変化し、ダッシュボードのアラート表示も消えます。 [図6] Silence Alert設定後 Samples Operatorの設定 インストール前に行ったリポジトリのミラーリングでは、インストールに必要なイメージのミラーリングが行われました。しかしながらイメージストリームで使われるほとんどのイメージは registry.redhat.io にあり、ミラーリングの作業ではこれらは対象外となります。 そのため、ネットワーク制限環境下のクラスターではこれらのイメージへの参照ができず、各イメージは参照エラーとなります。さらに一定時間経過度、Samples OperatorもDegratedになります。 対処法は二つあります。 Samples Operatorで全てのイメージの管理を無効化する Samples Operatorで管理除外するイメージを個別指定する *11 2019/12/1追記。 Samples Operatorの設定について別記事を書きました。管理除外する方法など詳細はこちら。 rheb.hatenablog.com 本記事では全てのイメージの管理の無効化について説明します。 全てのイメージの管理の無効化 下記のコマンドを実行します。 $ oc edit configs.samples.operator.openshift.io 下記の、 managementState: を Removed に変更します 変更前 〜省略〜 spec: architectures: - x86_64 managementState: Managed status: architectures: 〜省略〜 変更後 〜省略〜 spec: architectures: - x86_64 managementState: Removed status: architectures: 〜省略〜 設定変更後、Builds >Image Streamsに表示されるイメージ数が一気に減ります。 変更前 [図7] イメージ管理の設定変更前 変更後 [図8] イメージ管理の設定変更後 変更後に残っているものは、インストールペイロードの一部で、ミラーリング時に quay.io からミラーされたものです。またSamples Operator の管理対象外です。 Cluster Managerの登録 OpenShift Cluster Managerへアクセスします https://cloud.redhat.com 非接続のクラスターを登録します Register disconnected cluster を選択します [図9] クラスターの登録 クラスターの詳細情報を入力します [図10] クラスターの情報入力画面 Cluster ID: 必須 # Dashboards参照 Display Name: #任意の名前 Web Console URL: # 例) https://console-openshift-console.apps.test.example.local/dashboards Operating System: 必須 # 選択(Red Hat Enterprise Linux CoreOS/Red Hat Enterprise Linux) System Type: 必須 # 選択(Physical/Virtual) Number of vCPUs: 必須 # Worker Nodeの合計 Memory Capacity (GiB): # Worker Nodeの合計 Number of compute nodes: # Worker Nodeの台数 登録が完了すると自動登録された場合と同様の画面が出ますが、Monitoringタブには Disconnected cluster と表示され、Telemetryデータの受信が行われていないことが確認できます。 [図11] クラスターの登録後、Monitoring画面 アップグレード ネットワーク制限環境下のクラスターではOTAが使えません。 クラスターのアップグレードを行う場合は、ミラーレジストリーにアップグレードイメージをダウンロードし、そのイメージを指定して実行する必要があります。 アップグレードイメージのダウンロード 手順は本記事の「3. イメージリポジトリーのミラーリング」と同様です。 まず、ダウンロードバージョンの確認を行い、環境変数を設定します。 OCP_RELEASE= にアップグレード先のバージョンを指定し、リポジトリのミラーリング実行を実行します。 コマンドでのアップグレード 手動でアップグレードを行う場合は下記のocコマンドを使用します。下記はv4.2.7を指定したアップグレードの例です。 --to-image に指定するイメージ名は、ミラーリング成功結果の Update image: を参照してください。 $ oc adm upgrade --to-image=registry.test.example.local:5000/ocp4/openshift4:4.2.7 --allow-explicit-upgrade --force コマンド実行後に下記のように表示されたらアップグレードが開始しています。 Updating to release image registry.test.example.local:5000/ocp4/openshift4:4.2.7 以降は、通常のOTAと同様にWebコンソールでアップグレードの進捗を確認します [図12] アップグレード中の進捗 アップグレード完了後、指定したバージョンになっているか確認します。 Desired Release Image にはコマンドで指定したレジストリーミラーのイメージが指定されています。 [図13] アップグレード完了後 Operatorの利用 ネットワーク制限環境下でのOperatorの利用については、下記のドキュメントに記載があります。 第9章 ネットワークが制限された環境での Operator Lifecycle Manager の使用 4.2 | Red Hat Customer Portal 本記事では内容の詳細には触れませんが、ざっと下記のような流れになります。 quay.io からOperatorのパッケージをプルし、新しくカタログイメージにして、クラスタがアクセスできるローカルレジストリー（OCP内部も可）にプッシュする。クラスタから新規カタログを参照するように変更し、最後に oc image mirror でソースイメージをローカルレジストリーにプッシュする。 別記事 のイメージストリームのミラーと近い内容になっていますので、こちらも合わせて参考にしてみてください。 まとめ ネットワーク制限環境下でのインストール方法について解説しました。 ここまでに記載した通り、非常に多くの手順がありその上で制限も多くあります。 可能であればこの方法を行う前に、Proxy経由などでクラスターをインターネットに接続する方法をご検討ください。 Let's get Big Ideas ! 参考：Podmanコマンド イメージリポジトリーのミラーリング時に podman run を実行したのに、コンテナーが正常に起動しないなどの時に必要なコマンドの解説です。 Podmanコマンドのその他の詳細は、 man podman を実行するか、下記のドキュメントを参考にして下さい。 第7章 コンテナーのコマンドライン参照 Red Hat Enterprise Linux 8 | Red Hat Customer Portal コンテナーの確認 podman run を実行後、正常にコンテナが起動していない例 # podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 4ae1ce8416f3 docker.io/library/registry:2 /entrypoint.sh ?... 26 seconds ago Exited (127) 26 seconds ago mirror-registry コンテナーの停止 # podman stop mirror-registry 529d1a5c19faf973c1cadc6ce024a69d979c67e2b25527cc014c445a2e085757 コンテナーの削除 # podman rm mirror-registry 529d1a5c19faf973c1cadc6ce024a69d979c67e2b25527cc014c445a2e085757 # podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES ローカルコンテナーのイメージの確認 # podman images REPOSITORY TAG IMAGE ID CREATED SIZE docker.io/library/registry 2 f32a97de94e1 8 months ago 26.4 MB ローカルコンテナーのイメージの削除 上記で確認した IMAGE ID を指定して実行 # podman rmi f32a97de94e1 f32a97de94e13d29835a19851acd6cbc7979d1d50f703725541e44bb89a1ce91 # podman images ローカルコンテナーのイメージが削除されたことにより、リカバリーが完了です。 正常にコンテナーが起動した場合は、 podman stop podman start でコンテナーの停止、実行が行えます # podman stop mirror-registry a51a43a67d82adb46f3c3be3c0846cee59f353850054c569827afa3a94dc3d08 # podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a51a43a67d82 docker.io/library/registry:2 /entrypoint.sh /e... 2 days ago Exited (2) 6 seconds ago 0.0.0.0:5000->5000/tcp mirror-registry # podman start mirror-registry mirror-registry # podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a51a43a67d82 docker.io/library/registry:2 /entrypoint.sh /e... 2 days ago Up 5 seconds ago 0.0.0.0:5000->5000/tcp mirror-registry *1 : 本記事ではレジストリーホストの役割を明確にするために、踏み台サーバーとは別に構成しています。 *2 : インストールはサーバーGUIを使用。RHELの基本的な設定については、4.1 UPIインストール記事中の踏み台サーバーの構築を参照 *3 : 既存の認証局などがあればそちらを使っても構いません *4 : システム全体のトラストストアについては、次の記事を参照ください。 https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/security_guide/sec-shared-system-certificates *5 : 2019/12/5時点で、英語/日本語の公式ドキュメントがバックグラウンド起動に修正されています。 *6 : 以降の3.3 リポジトリのミラーリング実行時に、2つのプルシークレット情報が無いとミラーリングに失敗するため。英語のblog記事には手順記載あり。フィードバックは登録されているので、ドキュメント修正待ち。 *7 : 現在はコマンドで入手する方法が無いためブラウザで実行してください *8 : 2.1追加作業を参照 *9 : ドキュメントにはオプションにプルシークレットの指定が無いので追加。これもドキュメントの修正待ち。 *10 : 確認できた違いとしては、Desired Release Imageに表示されるイメージ名がquay.ioなのかローカルレジストリーなのか、程度 *11 : これについてだけでも結構なボリュームの内容があるので、別記事にする予定です。→書きました。

皆さんこんにちは、Red Hat ソリューションアーキテクトの岡野です。 つい先日 Ansible Tower 3.6 がリリースされました！ 細かい機能アップはたくさんあるのですが、ここでは注目の新機能 3つをご紹介します！！ 1. Webhook に対応 実はこれ、私が密かにずーっと待っていた機能です。♪ コード管理者が中心となり、端末の状態を全て管理できる素敵な機能。♬ Ansible Tower は GitHub 等のバージョン管理システムと連携して Playbook のバージョン管理を行うことが可能ですが、今回、GitHub / GitLab でサポートされた Webhook 機能を利用すると、Git 上の Playbook の更新をトリガーにした Ansible Tower のジョブテンプレートやワークフローテンプレートの自動起動が可能となります！つまり、コード管理者の意のままに管理対象ノードを操ることが可能となるとっても素敵な機能なのです。 　　 2. ワークフローテンプレートの中で承認機能をサポート Ansible Tower の便利な機能としてワークフローテンプレートがあります。システム別・機能別などの理由で分断化された Playbook をつなぎ合わせて実行するとても便利な機能なのですが、一般的にエンタープライズで利用されているワークフローと比較すると承認機能がサポートされていませんでした。ここに、ついに承認機能が追加されました！！利用方法は以下の通りです。 　ワークフローに、”Approve 処理を行うノード” を追加 　※以下のキャプチャーで Wait で示されているノードです。 　 　ワークフローテンプレートのパーミッションで、承認者を追加 　 設定はこれだけです。ワークフローテンプレートを実行すると、上記 Wait 処理を定義したノードで承認待ちとなります。承認者で Ansible Tower にログインすると、以下のような承認依頼の画面が表示され、Approve / Deny を選択・実行することが出来ます。Approve が選択されるとワークフローが先に進み、Deny が選択されるとワークフローテンプレートが失敗で終了します。承認依頼は、Ansible Tower の機能を使って通知することが可能です。 　 3. 通知内容のカスタマイズをサポート 上記したワークフローの承認機能でも利用される通知機能ですが、前バージョンまでは、送信される内容がジョブの成否のみにとどまっていました。詳細は、Ansible Tower にログインして確認してね、という感じです。これが Ansible Tower 3.6 では内容のカスタマイズが可能となりました！実はこれ、結構お客さんから問い合わせの多い機能で、今までは ”Tower にログインしてで確認しましょう！”と苦し紛れに申し上げていたのですが、これからは、変数で自由に内容を定義することが出来るようになります。♪ その他の新機能については以下のリリースノートをご確認ください https://docs.ansible.com/ansible-tower/latest/html/release-notes/relnotes.html#release-notes-for-3-6-x いかがでしたでしょうか？とても素敵な機能アップだと思いませんか？ 特にワークフローテンプレートに関しては最近 Ansible Tower のバージョンアップとともに大幅に機能アップが図られています。 是非 Ansible Tower で運用の Full Automation を実現しましょう！！

こんにちは、Red Hat SSA の小杉です。 昨今、 Data Virtualization というキーワードをよく聞くようになりました。今年開催された AWS Summit 2019 では私はストレージベンダーの技術者として参加していましたが、目の前が Data Virtualization のブースでした。 Teiid - Data Virtualization (Tech Preview 2019–07) Red Hat は JBoss Data Virtualization というプロダクトを取り扱っていましたが、2018年8月に販売を終了しました。 しかし、 Data Virtualization は Red Hat Integration の一部として復活を予定しています。 現在、Data Virtualization は Tech Preview にあります。今回 Data Virtualization の UpStream である Teiid SpringBoot を試してみました(Tech Preview と同じ内容です)。 medium.com Teiid Operator(Community版) また、OpenShift/Kubernetes 上での運用を楽にする Operator、Teiid Operator が Community 版でリリースされています。 仮想データベースをカスタムリソースとして定義し、Opeartor 経由でコーディングすることなく作成できるようになっています。 medium.com そして、従来の Data Virtualization との大きな違いは Fuse Online という OpenShift 上に乗るインテグレーション製品を利用してローコードで Data Virtualization を構築していける点にあります。Fuse Online 自体は Syndesis というアップストリームプロダクトをベースに開発されていますが、その下で動く Integration の Runtime は Camel(と Teiid SpringBoot になる予定)です。 Camel については Red Hat Forum にて Knative や QUARKUS など最新の情報を交えて弊社からセッションが予定されています( AP09 )！ぜひご登録ください！ reg.redhat-forum.jp

Red Hatの森若です。 Red Hat Enterprise Linux 8 のコードネームは、 Ootpa となっています。一般的な単語や地名ではないので、ほとんどの方は意味がわからないと思います。 ootpa "ootpa" とは 2016年に亡くなった、Red Hatのエンジニアであった Larry Troan が社内のIRC(internet relay chat)上で使っていたニックネームです。RHEL 8のコードネームは彼を称えてつけられたものです。 ニックネームの由来 さて、"ootpa" というニックネームにも由来があり、話はRed Hatの創業直後にまでさかのぼります。 当時 rpm や anaconda などの開発をしていたRed Hatのエンジニア Erik Troan はイニシャルの "ewt" をIRCのニックネームとして使っていました。彼は "ewt" をもじって "oot" と呼ばれていました。最初に彼を "oot" と呼びはじめたのは Alan Cox であったそうです。 Larry Troanは Erik Troan の父親です。 "oot" の父 ("pa") ということで "ootpa" というニックネームになりました。

Red Hatの福岡オフィスでソリューションアーキテクトをしている田中司恩です。 OpenShift 4.2がGAになってからしばらく経ちました。みなさま検証などは進んでいますでしょうか？ 今回はOpenShift 4.2をUPIインストールするにあたり、4.1から変更があった内容についていくつかピックアップして解説いたします。 本記事で紹介する内容以外は、4.1の手順で4.2 UPIインストールが可能です。 説明に使用する環境構成は以前の記事と同様ですので、合わせてこちらもご参照ください。 rheb.hatenablog.com 本記事では下記の内容について説明いたします。 UPIインストール環境 ネットワーク制限環境下およびProxy環境下でのインストール マスターノードがスケジュール対象になる 4.2 UPIベアメタルインストールの日本語ドキュメントは下記になります。 第6章 ベアメタルへのインストール 4.2 | Red Hat Customer Portal UPIインストール環境 UPIインストールでサポートされる環境にGCPが追加されました。現時点でサポートされる環境は下記の通りです。 4.2 UPIインストール環境 AWS GCP VMware vSphere ベアメタル ネットワーク制限環境下およびProxy環境下でのインストール 企業内の環境において、クラスタからインターネットへ接続ができない環境や、Proxyを経由してアクセスする環境でのインストールができるようになりました。 1.2. 新機能および改良された機能 4.2 | Red Hat Customer Portal 1.2.1.3. ネットワークが制限されたインストール OpenShift Container Platform 4.2 では、接続するネットワークが制限された環境での OpenShift Container Platform クラスターのインストールおよび更新のサポートが導入されました。 ローカルにミラーのコンテナレジストリを構築し、OpenShift 4.2のインストール時にそこからイメージリポジトリをミラーする方法です。 *1 ネットワーク制限環境下のインストール 2019/11/24追記 ネットワークが制限された環境下でのインストールについて、別記事を書きました。 手順などの詳細は下記の記事を参考にしてください。 rheb.hatenablog.com 1.2.1.4. クラスター全体の egress プロキシー OpenShift Container Platform 4.2 では、ユーザーによってプロビジョニングされるインフラストラクチャーでの企業プロキシーサーバーを使用した OpenShift Container Platform クラスターのインストールおよび更新のサポートが導入されました。 こちらについてはすでに別記事を書いていますので、下記記事を参考にしてください。 rheb.hatenablog.com マスターノードがスケジュール対象になる これは地味な変更点なのですが、4.1と同じ感覚で4.2のインストールテストをしていて「あれ？」となったので、詳しく説明いたします。 *2 まず、OpenShift 4.2を4.1と同じ手順でUPIインストールすると、ノードのROLESが下記のようになります。 # oc get nodes NAME STATUS ROLES AGE VERSION master-0 Ready master,worker 20m v1.14.6+463c73f1f master-1 Ready master,worker 20m v1.14.6+463c73f1f master-2 Ready master,worker 20m v1.14.6+463c73f1f worker-0 Ready worker 20m v1.14.6+463c73f1f worker-1 Ready worker 20m v1.14.6+463c73f1f 注目頂きたいのが、master-0,1,2 のROLESです。 4.1までであれば master となるべきところが master,worker となっています。 これはマスターノードもスケジュール対象となり、アプリケーションのPodが稼働する状態となっていることを表しています。 1.2. 新機能および改良された機能 4.2 | Red Hat Customer Portal 1.2.6.3. マスターノードがスケジュール対象になる OpenShift Container Platform 4.2 では、マスターノードがスケジュール対象になりました。詳細は、「Working with nodes」を参照してください。 4.2.4. Configuring master nodes as schedulable *3 By default, master nodes are not schedulable. However, if your cluster does not contain any worker nodes, then master nodes are marked schedulable by default. デフォルトではマスターノードはスケジュール対象ではないですが、1台もワーカーノードが無いとマスターノードがスケジュール対象になる、ということです。 UPIでインストールの作業時にインストール設定ファイル install-config.yaml を作成しますが、この事象はその内容に関係します。 インストール設定ファイルの内容はこのような内容です。 apiVersion: v1 baseDomain: example.local compute: - hyperthreading: Enabled name: worker replicas: 0 controlPlane: hyperthreading: Enabled name: master replicas: 3 metadata: name: test networking: clusterNetworks: - cidr: 10.128.0.0/14 hostPrefix: 23 networkType: OpenShiftSDN serviceNetwork: - 172.30.0.0/16 platform: none: {} pullSecret: '{"auths":{"cloud.openshift.com":{"auth": ..<省略>.. ==","email":"XXX@XXX"}}}' sshKey: 'ssh-rsa AAAA...' workerのreplicasが 0 になっているのが確認できます。 *4 この設定でインストールを行うため、その結果マスターノードがスケジュール対象になってしまうということです。 回避策はインストール前か後に行う、2通りの方法があります。 1. インストール前に行う方法 インストールディレクトリを作成し、作成したインストール設定ファイルをコピーします。 インストールディレクトリ： bare-metal $ mkdir bare-metal $ vi install-config.yaml $ cp install-config.yaml bare-metal/ マニフェストファイルを作成します $ openshift-install create manifests --dir=bare-metal マニフェスト作成後のインストールディレクトリ内は、下記のようになります。 $ tree bare-metal bare-metal ├── manifests │ ├── 04-openshift-machine-config-operator.yaml │ ├── cluster-config.yaml │ ├── cluster-dns-02-config.yml │ ├── cluster-infrastructure-02-config.yml │ ├── cluster-ingress-02-config.yml │ ├── cluster-network-01-crd.yml │ ├── cluster-network-02-config.yml │ ├── cluster-proxy-01-config.yaml │ ├── cluster-scheduler-02-config.yml │ ├── cvo-overrides.yaml │ ├── etcd-ca-bundle-configmap.yaml │ ├── etcd-client-secret.yaml │ ├── etcd-host-service-endpoints.yaml │ ├── etcd-host-service.yaml │ ├── etcd-metric-client-secret.yaml │ ├── etcd-metric-serving-ca-configmap.yaml │ ├── etcd-metric-signer-secret.yaml │ ├── etcd-namespace.yaml │ ├── etcd-service.yaml │ ├── etcd-serving-ca-configmap.yaml │ ├── etcd-signer-secret.yaml │ ├── kube-cloud-config.yaml │ ├── kube-system-configmap-root-ca.yaml │ ├── machine-config-server-tls-secret.yaml │ └── openshift-config-secret-pull-secret.yaml └── openshift ├── 99_kubeadmin-password-secret.yaml ├── 99_openshift-cluster-api_master-user-data-secret.yaml ├── 99_openshift-cluster-api_worker-user-data-secret.yaml ├── 99_openshift-machineconfig_master.yaml └── 99_openshift-machineconfig_worker.yaml 2 directories, 30 files インストールディレクト内の manifests/cluster-scheduler-02-config.yml を編集します。 mastersSchedulable: true となっている行を、 mastersSchedulable: false に変更します。 Ignition 設定ファイルを作成します $ openshift-install create ignition-configs --dir=bare-metal このコマンド実行後は、マニフェストファイルは全て消えます。 後は、Ignition 設定ファイルを配置して通常通りインストール作業を実行します。 2. インストール後に行う方法 この方法は、ドキュメントの 4.2.4. Configuring master nodes as schedulable に記載の方法です。 下記のコマンドを実行し、リソースを編集します $ oc edit schedulers.config.openshift.io cluster mastersSchedulable: true となっている行を、 mastersSchedulable: false に変更します。 変更後はすぐに反映され、マスターノードのROLESが master のみになります。 なお、インストール前に設定変更せずに openshift-install create ignition-configs を実行した場合、下記のように警告が出ます。 このことからインストール前に注意喚起が行われていることが分かります。 $ openshift-install create ignition-configs --dir=bare-metal INFO Consuming "Install Config" from target directory WARNING Making control-plane schedulable by setting MastersSchedulable to true for Scheduler cluster settings まとめ OpenShift 4.2 UPIインストールにおける、4.1からの変更点をいくつかピックアップして紹介しました。 4.2では様々な機能面での追加だけでなく、GUIの見た目の変更も多数あります。 特にDeveloper Consoleは触ってみたくなるUIになっていますので、是非4.2をインストールして新機能を体験してみてください。 Let's get Big Ideas ! *1 : アップデートイメージの入手元の環境は、インターネットへのアクセスができる必要があります *2 : 小規模環境でのテストならそのままでもほとんど影響は無いと思われますが、気になったので調べてみました *3 : 2019年10月30日現在、英語版のみ公開のため *4 : UPIでのインストール仕様のため、wokerのreplicasを0にする必要があり、現時点で回避方法が無い…

Red Hatの森若です。 ※ Image Builder自体の紹介については以下の記事をごらんください。 rheb.hatenablog.com RHEL 8.1でImage BuilderがGCPに対応するらしい RHEL 8.1 beta (11月予定なのでGAももうすぐですね) のリリースノートを読んでいると、以下のような記述がありました。 Image Builder now supports image creation for more cloud providers With this update, the Image Builder expanded the number of Cloud Providers that the Image Builder can create an image for. As a result, now you can create RHEL images that can be deployed also on Google Cloud and Alibaba Cloud as well as run the custom instances on these platforms. (BZ#1689140) GCPで使える仮想マシンイメージはrawをtar.gzに収めた形式のファイルをgcloudコマンドで送ります。従来でもraw形式で仮想マシンイメージを作ってtarに入れればできるといえばできていました。もう少しいろいろやっているのかもしれません。見てみましょう。 upstreamのissueを見る Image Builderのupstreamであるloraxプロジェクトをみると、対応するpull requestがあります。 github.com コメントを読むとGCPはkernel optionの"rhgb quiet" を消すことを推奨していますが消していないことがわかります。 ここでfilesタブを見るとこのPRで修正されたファイル群を閲覧できます。 github.com disk.rawのようなパーティションつきイメージを作ってdisk.tar.gz に収めるtar対応、それを使う"google"というイメージタイプの定義、専用kickstartやコマンドラインツールの対応、テストなどが含まれています。 kickstartファイルを見る この中で技術的に気になるところはなんといってもkickstart部分でしょう。kickstartはRHELのインストーラであるanacondaで自動インストールするために使われるファイルです。対話的なGUIやテキストベースのUIよりもこまかい処理が可能です。 https://github.com/weldr/lorax/blob/rhel8.1-branch/share/composer/google.ks このファイルを見ると、firewallの無効化、MTUサイズ、IPv6の無効化、dhcpを使うこと、タイムゾーンをUTCにすること、irqbalanceの無効化、rootユーザのロックアウトなど、GCPで推奨されている設定が含まれています。 cloud.google.com cloud.google.com GCP推奨との違い 私が見た限りでは以下の点はGCPの推奨から外れているようです。 パッケージの自動更新を設定しない denyhosts, pam_cracklib, pam_tally を設定しない(RHELに含まれていません) linuxコマンドラインの "rhgb quiet" がそのまま CAP_SYS_MODULEの無効化はしない System.map の削除はしない まとめ RHEL 8のImage Builder(lorax, weldr)は各種の仮想マシンイメージを作成できます。ぜひ試してみてください。

こんにちは、Red Hat の SSA 小杉です。 OpenShift 上で Kafka クラスターを AMQ Streams Operator を使って起動し、Kafka トピックにメッセージを格納、取り出すアプリケーションを QUARKUS のサンプルを使ってデプロイしてみました。 medium.com Kafka を検討されている方、他社からサポートを乗り換えようと考えている方、是非 OpenShift + AMQ Streams の組み合わせで検討していただければと思います！

みなさんこんにちは、Red Hatでソリューションアーキテクトをしている金森です。 唐突ですが、なんとRed Hatと書く際にはRedとHatの間に [半角スペース] が入ることをご存知でしたか？ 実は redhat でも Redhat でもなく、 Red Hat が正しい会社名記述です。 今日はこれだけ覚えてもらえると本当に嬉しいです。 Red Hat社内の人間もついうっかり間違えて使ってたりするので、Red Hat半角スペース警察に取り締られたりします。 ぜひ、みなさんも身近な半角スペースなしRed Hatterを取り締まってみてくださいね！ さて、大事なことは伝え終わったのですが、10/16に OpenShift 4.2がリリース されました！ 今回のリリースも様々な見所が数多くあるのですが、それはさておき そもそもPaaSとかOpenShift(k8s,コンテナ)ってなんの旨味があるの？ どんな効果を出しているの？DXとどう関係あるの？ 既存システムのコンテナ化ってどう考えればいいの？ 新しい基盤だけ入れればいいの？ という素朴な疑問を持っている人もいると思います。 何かしらのヒントになればと思い、このポストでは残りの余白を使って今年5月のRed Hat Summitで発表されたユーザーの事例を紹介しようと思います。 前回は Microsoftの17,000台のネットワークをAnsibleTowerで自動化した事例を紹介 しましたが、 今回はRed Hat OpenShift Container Platformのヘビーユーザーで世界第2位のエアラインDelta航空の事例、 Driving agility in business transformation at Delta Airlines with stability and sustenance （意訳:ビジネスの変革を成し遂げるため、デルタ航空ではどのように安定性と継続性を両立させたままアジリティを向上させていったのか)をお届けします。 スピーカーであるデルタ航空のディレクター Doug Keskey氏がOpenShiftをどのように使い始めたのか？そのテクノロジーをどう最大限に活用しているのか？既存アプリケーションを何から移行させたのか？を解説します。 紹介するセッションのフルの資料やアブストは Red Hat Summit 2019のページから 確認できます。 ではこのセクションより、セッション本編に入りたいと思います。 Driving agility in business transformation at Delta Airlines with stability and sustenance タイトル デルタという会社とエアラインというビジネス デルタ航空 Doug Keskey氏 デルタ航空はアメリカにある世界で最も大きな航空会社のうちの一つです。300以上の国内線があり、国際線も数多く飛ばしています。 我々が人を雇う際の口説き文句でよく言うのですが、このエアラインで働くと言うことは単純なキャリアを積むと言うことではなく、あなたの生き方に繋がることになるだろうと言ったりもします。 Deltaにいる限り、世界があなたの挑戦する場で、そこがあなたの生きる場所なのだと。 航空会社と言う領域で働く上で、とても面白いメジャーな問題として、エアラインの運行は、それ自体が非常に複雑な物流の上に成り立っていると言うのがあります。 あなたが飛行機に乗るとき、まずゲートで登場手続きをしたのちに飛行機へ乗り込みますが、あなたや乗客、それと同じく動く預け荷物、その他の飛行機運行に必要なもの全ての可動部分を考えるなら、乗客、そこに必要な乗組員、飛行機の整備、運行、ケータリングなどなど、とても多くのロジスティックと最適化が必要になってきます。 それらの問題は516の主要な都市への直行、乗り継ぎを含めたフライトで、毎日5,000回程度発生しています。またそこには提携航空会社との連携も発生します。 デルタ航空は Fortune 500で最も尊敬すべき会社にも選出されたこともあり、お客様に選んでいただいていると言うことを自負もしています。実際、過去9年間トラベル・航空会社のカテゴリーで１番の評価をいただいています。 トップ企業であると言うことは、いつか追い抜かれるかもしれないと言う状態かもしれませんが、我々はそうならないよう毎日とても楽しく仕事をしています。 従業員の働く環境についても、透明性がとても高く軍隊のように非常に厳しい評価をすると評判の調査会社の調査結果においても、女性やマイノリティのメンバーにとっても素晴らしい場所であると言う評価を得ています。 そういったこともあって、非常に良い状態を保ててるのではないかと思っています。 一方で、ビジネス上の問題を解決するということについても、とても楽しい状態で進められています。 それもあって、デルタ航空というのは働くのにはとても良い場所と言えるでしょう。 創業90年の会社がビジネス変革のために実現するアプリケーション・モダナイゼーション さて、ここからまず我々の全体的なアプリケーション・モダナイゼーションのイニシアチブについてお話しましょう。 デルタの変革ジャーニーにおけるイニシアチブ デルタは創業90年でメインフレームの時代からITを活用してきたため、社内には多岐にわたるアプリケーションが溢れていました。 90歳の会社を想像してみてください。 社内には90年代どころではなく、おそらく70年代ひょっとしたら60年代から動いている何かを簡単に見つけることができます。 デルタ航空のアプリケーションポートフォリオの大部分は、過去25年から30年に渡って開発されており、最近では腐ったシステムの上にさらに新しい機能を追加構築するような傾向がありました。 そのような状態に対して、我々はアプリケーションをより俊敏に移行できる方法を知ろうと試みました。 また多くの技術的な負債を引退させる方法を実現しようとしています。 所有しているアプリケーションの俊敏性を高め、技術的な負債(例えばスケールを簡単にできるようにしたいのに、旧式アーキテクチャに囲い込まれているためできないようなもの)を引退させるためアプリケーションの変革を決意しました。 これらの新しいテクノロジー領域、クラウドベースのテクノロジーを適用することができれば、動的なスケーリングができるなどができれば、アプリケーションのデプロイをもっとダイナミックにし、レバレッジを変えることができるのではないかというところがモチベーションです。 OpenShiftは我々にとってPaaSの機能を提供してくれたプラットフォームでもありますが、単純に基盤を作り直す・保有する、というリソースの観点だけではなく開発プロセスやそれに関わる様々なツールも刷新することが重要だと感じており、まさにそれらも提供してくれるものでした。 アプリケーションモダナイゼーションを行うプロセスにおいては、DevOpsの方法論で、PaaSをツールとして利用し、CI/CDタイプの開発プロセスを全てのアプリケーションへ採用・適用しました。 これらはモダナイゼーションという目的を達成するための手法として必要なことでしたし、これらを採用することで実際にモダナイゼーションが達成できていると考えています。 一つの大きなポイントとして、セキュリティの確保がありました。 Red Hat Summitの基調講演でも弊社のCIOがお話した通り 、セキュリティの観点でも確実にかつ簡単に管理ができるものを利用する必要があります。 確実なセキュリティを確保する要素もCI/CDのプロセスへ組み込みました。 現在では、プラットフォーム自体のセキュリティを維持するだけでなく、プロダクト内でCodeとしてセキュリティを実装・維持できるようになったと考えています。 実際にCI/CDプロセスにおいて、自動的なスキャニングを実施しコード上でもセキュリティを維持できています。 Delta航空のビジネス変革 3つのプログラムイニシアチブ 3つのイニシアチブ 少しお話をしたように、他のイニシアチブもあります。 スライドの一番右に書いてある技術的なアップグレードについてはここまでに少しお話しました。 また最新のプラットフォームでセキュアにたくさんのものを実行できて、さらに迅速になったということを簡単にお話したつもりです。 一番左(Dojo Program)について。 これが本当に困難でした。 ビジネスプロセスの革新について、開発チームと話をするのは本当に大変でした。 開発者、MBA、ビジネスパートナーなどを巻き込み、アジャイルタイプの開発手法論へとシフトさせたのです。 ここではこれらについて多くを言及しませんが、このDojoプログラムを無しには、全ての関係者の間にあった距離感をなくしワンチームとするのは本当に困難だったと思います。 3週間でアジャイルチームを立ち上げ、当たり前のようにPaaSやツールセットを使いこなし、DevOpsを実現する教育プログラム Dojoと名付けたアジャイルチーム育成プログラム デルタでは、Dojoプログラムという名前で集中してPaaSを利用することについて学ばせることにしました。 具体的には、3週間でチームを立ち上げ、アジャイルに適用させます。 APIの使い方、DevOpsのやり方を学びます。 デザイン思考、アジャイル、クラウド技術など、プロセスに関わることなどです。 そのための、強力なツールのセット、それらをどう使って新しい開発を行うのか、ボトムアップで設計し、学ぶことで、テクノロジーを最大限に活用しアプリケーションを設計することができます。 このスライドに記述されているものは、実際に現在デルタで実行しているプログラムの一つです。 これらの手法は Youtubeでも公開しています 。 PaaSの採用とテクノロジーの活用 現在、我々は明確にPaaSへ移行しようと考えており、戦略的にもOpenShift Platformを採用しています。 技術的な詳細は話しませんが、テクノロジーをいかに組織論やプロセスにつなげていくかについてをお話します。 繰り返しますが、我々は数百から数千の既存アプリケーションを抱えていました。 我々のプロジェクトは、２つのトラックからなってます。 インフラストラクチャのトラックでは、十分なコンフィグレーションセッティングやインストールなど、基本的にどうすればプラットフォームを利用できるのかを十分に知るための準備を実施します。 もう一つは開発コミュニティ向けトラックです。 企業向けのアプリケーション開発を志向しています。これらに開発ルールを適用し、アプリケーションを効率よくPaaSに取り込んでいく方法を見つけていきたいと考えています。 製品採用から既存アプリケーションのPaaS移行の道のり DeltaのPaaSジャーニー PaaSへの移行対象は、全く新しいアプリケーションではありません。 既存のアプリケーションから選定しました。 また、我々は移行の中で既存アプリケーションを止めて、アプリケーション全てを書き直すようなつもりはありませんでした。 色々と考えた末、長年のパートナーシップにあったTCS(タタコンサルティングサービス)と協力しました。 PaaSへの移行において、複数あるアプリケーションのうちからどれを選ぶのか？しかも600~2000くらいあるアプリから。 その中に、非常に環境と密接に結びついているアプリケーションがありました。 つまり、モノリシックなアプリケーションをPaaSへコンテナ化して移行してみました。 大きなモノリシックアプリをコンテナ化したのです。 必ずしも、マイクロサービスやそれに類するものに分割するのではなく、アプリケーションを利用するために必要なOpenShiftへの移行作業だけを行いました。 それだけでも現状クラウド化した効果はでています。 本当はクラウドネイティブのような作りが望ましいのでしょうが、それらはもっとグリーンフィールドタイプの開発や、より初期の開発であったり、幾つかの理由で完全にリファクタリングするような場合にのみ実行することにしています。 このセッション内で話すのは、既存のアプリケーションをコンテナ化したという話です。 デルタは、様々な製品と検討・比較したのち、2017年にOpenShiftをデルタのPaaSに位置付けるという戦略的な決定をしました。 その後、2018年初頭に、パイロットアプリケーションを構築し、APIを実行したりしました。 それらのいくつかは今も本番環境で稼働していますし、その頃(2018年第一四半期)も相当に満足をしていました。 しかし、試みを加速させるためにはプラットフォームの能力を引き出す必要があります。 そこで、2018年の第二四半期では再度メソドロジーを理解するためのプロセスを実行しました。 簡単に聞こえるかもしれませんが、非常にハードで、経験豊富なチーム(TCS)と協力する必要がありました。 第三四半期に作業を開始し、おそらく40程度のアプリを並行してオンボーディングしました。 そして年末には実際に環境下へ新しいプロセスを通してアプリケーションのデプロイを行えるようになりました。 現在では、さらに多くのアプリケーションを追加できていますし、スケールアップしてきています。 実際に物理的な調達が間に合わず一時的なリソースでOpenShiftを稼働させ全てのアプリケーションを構築てもらったり稼働させたりもしました。 それらはテンポラリであり恒久的な環境ではなかったのですが、おそらく、私の見解ではユーザはそのような状況だったとは気が付いてもいないでしょう。 新しい環境にコンテナを移動させ、実行することは非常に簡単に実行できました。 そして2019年の第一四半期の終わりまでにプロダクション環境への移行は非常にうまくいきました。 その結果として、我々はさらに大胆になって行きました。 ミッションクリティカルなアプリも移行対象へ 移行対象にはミッションクリティカルなタイプのアプリケーションもありました。 35年以上航空会社で生き残りたいなら、クリティカルではないアプリケーションを移行対象として選ぶべきなのでしょうが、正直重要でないアプリケーションを移行したとしてもあまり意味も価値はありません。 結果的に57のアプリケーションを本番環境へ移行しました。 現在は、このインフラストラクチャを利用して俊敏性を高め、DevOpsを実現し、プラットフォームに依存しないアプリケーションを追加していけることを楽しみにしています。またこのテクノロジーを利用してさらにアジリティを高めていくことも計画しています。 我々の環境に合わせ、複数の物理的な場所にまたがり、アプリケーションを展開することも検討しています。 ですが今日はパブリッククラウドについては多く言及しません。 私たちが目的としていたことは、OpenShiftのPaaS環境を用いて、アジャイルとDevOpsをベースとした組織を作り上げ、アプリケーションのデリバリーを加速することでした。 そのためには、先ほども言いましたがDevOpsの手法なしでは絶対に成し遂げられません。 実際やってみると、アプリケーション自体の多くはわかりやすく、簡単な移行でした。 もちろん、少なからず影響はあり、そのためにいくつかのアプリケーションは更新したり、クラウドフレンドリーな形へ変更してあげる必要がありました。 それらの変更を実行するためにOpenShiftの環境があるので、大切な要素である、”12ファクター”を知っておく必要がありますし、基礎となるプラットフォームから様々な依存を分離させた形でアプリケーションを実行する形にすることが重要なカギになります。 こういった重要なポイントからも、我々はナレッジと専門知識を持ったチームを作りたいと考えるようになったのです。 重要なポイントを理解し、何かのアイディアが生まれたならば、それらをサポートするプロセスを確立する必要があると考えました。ビジネスを作り出すプロセスとして現行の開発手法の再構築を試みたのです。 そして、そのプロセスを通じて、チームをハンドルする必要があったのです。 我々はアプリケーションを開発する手法を変えました。 また、Day2オペレーションにおいては、先進的な開発リードをするチームが去ったとしてもアプリケーションをサポートができる状態が必要です。 そのような状態を作ることも目的でした。 Day2オペレーションにおいてビジネスを停滞させないために 運用モデルについて ではどうしたのか？ Operating Modelを確立しようと考えました。 中央集権的なチームを作りました。それらを中心とした、オペレーティングモデルです。 いかにPaaSを使いこなすか、移行、パフォーマンス監視や運用、Toolの使いかたまで含めたプロセスをこのチームが提供しています。 デルタのメンバーも、最初は自分たちのレガシーアプリケーションを単純にどう個別に運用するかを考えていましたが、だんだんとどうやって効率よく最新のDevOpsツールやOpenShiftを使いこなすか、移行するかを考えるようになり、彼らをPaaSのアクセラレーションチームがサポートしています。 またこのプログラムを通じることで、これまでどのように既存のアプリケーションをケアしてきたかもわかるようになってきます。 プラットフォームチームのメンバーも開発者とペアプログラミングを実施しています。 開発の仕方、アプリケーションの移行の仕方をツールもセットで学びます。 結果、アプリケーションをプロダクションへ移行する準備ができますし、サポートする準備もできるようになります。 彼らがこのプログラムから卒業する時には移行準備ができているということです。 そして次のような方法論も整備しました。 既存アプリケーションをPaaSへ移行するための方法論を確立 既存アプリケーションのPaaSへ移行するまでの道のり PaaSでアプリケーションイメージを実行するには、いくつかのコードをアップグレードする必要があったりします。 しかし、その他の要素で我々はCodeのUpgradeを行なっていました。 それは、開発チームが開発中に利用できるDevOpsツールを利用できるようにアプリケーションを移行することでした。 そしてこれらのツールは私がdojoプログラムの中で少し話したものでもあります。 これらの利用されているツールは、全てのチームが非常に愛用しているツールです。これらは私たちのPaaSを提供するという労力からは独立したものです。 それにもかかわらず、利用されているツールは私たちがPaaSで提供しているものと一致しています。 人とアプリケーションがDevOpsツールを利用できるようになったら、次にPaaSでサポートされているイメージを実行するため、アプリケーションを揉みほぐしていく必要があります。 PaaSを活用するため、 『12ファクター』に合わせていくのです。 ロギングとモニタリングを標準化したりもします。 デプロイメントも完全に自動化しました。 これによって、アプリケーションの開発チームがプラットフォームチームと会話をしつつ開発を行えるようになりました。昔から連携はしていましたが、今はよりスムーズになりました。 車輪の再発明を防ぎ、ビジネス変革へ開発チームをフォーカスさせる 40以上の実装のパターン化 中央集権的なグループを作ることの先ほどとは異なった観点でのメリットは、様々な実装のパターン化ができるという事実に基づくでしょう。 実装における車輪の再発明を防ぐことができるのです。 我々は40ほどのパターンを確立してそれらを当てはめて行きました。 それらをお全てテンプレート化したのです。 プラットフォームチームとの協力の結果、このページに書いてあるようなとても素晴らしいインデックスを作ることができました。 PaaSを使うことによるメリットとは これは、私から見たプロセスなど含めて一般的な利益をまとめたようなスライドですが、私が認識した利点をあげます。 環境が一貫していること。 これは本当に素晴らしく、これまでのように存在していないものや不確実なものに対してテストを実行するようなことが一切なくなりました。 レジリエンス。 ブルーグリーンデプロイメント。 扱いやすく、ポータビリティがあることなど。 こういった利益を本番環境で確認し実感できたことが、本当に私自信を興奮させました。 Deltaで使われている他のRed Hatプロダクトたち 他にも、Red Hatのプロダクトを利用しています。 ここでは使用しているいくつかを紹介します。 Ansibleは強力な自動化のツールで、PaaSを取り巻くNWやストレージ、PFの領域や運用の領域で使われており、AnsibleTowerによって様々な3rd Party製品やチームとの連携を可能にしています。リードタイム削減をしてアジリティを高めるために本当に良いツールです。 RHELもセキュリティ担保のための基本的なパーツですし、限定的なアクセスのみを許可している閉ざされたEnterpriseなNW環境で迅速な開発を行うにはSatelliteがなければメンバーは形だけの意味のないセキュリティのおままごとで無駄な時間や手間を生み出すことになるでしょう。 そういった塀だけを高くすることがエンタープライズのセキュリティであるという考え方に基づいたプラットフォームや運用は、やがて全てに悪影響を発生させ、限定的で意味のない開発プロセスを作りだしますし、塀の中の本質的なセキュリティ脆弱性はいつまでも埋めることはできないでしょう。 PaaSへの道のりでの学びとは ここではスライドの2番目のポイント(Enterprise application pre-assessment and repeatable pattern identification)について話しましょう。 確立した40のインテグレーションパターンについて述べました。 これをやがてはアプリケーションにも持ち込みたいと思っています。 アプリケーションではいくつか課題もあるかもしれません。しかし、今我々はそれらを環境に持ち込むために色々な厄介ごとを取り除く良い方法をすでに持っているのです。 プラットフォームチームと協力してすでにOpenShiftのマーケットプレースカタログにテンプレートの追加も実施できました。 共通言語を学び、組織を変革し、Fun journeyを続けるDelta 私たちが抱えていた最大の課題は、全員を集めて共通言語を学ぶことでした。 単純にいってしまうとツールとプロセス、設定方法を学ぶことです。 組織全体をまとめることで、共通のツールを学ぶ動機付けをし、この学ぶというプロセスの中でさらにたくさんのことを学びました。 トレーニングをする、というのも大事ですが、実務を目の前にした時にトレーニングで得た概念は消えてしまいます。 ホワイトボードの上で描かれることと、キーボードを用いて実行されることは単純に見えるけど同じにすることは本当に難しい。 結局、いつかは開発者の考えを変えなければならない。 これらの道のりは本当に大変だった。 でも、“It's been a fun journey”です。 以上で私の話を終わります。 ご静聴どうもありがとうございました。 Delta航空のOpenShift導入事例、いかがでしたでしょうか？ 皆さんのDXの参考になれば幸いです。 ではまたどこかでお会いしましょう！ Red Hat金森 今すぐ試したい人は こちらからどうぞ ！ OSSの最新事例やセミナー情報をGetしよう www.redhat.com

Red Hatの福岡オフィスでソリューションアーキテクトをしている田中司恩です。 今回はOpenShift 4.2で追加される「Proxy環境下でのインストール（Cluster-wide Proxy）」について説明していきます。 *1 説明に使用する環境構成は前回記事と同様ですので、合わせてこちらもご参照ください。 rheb.hatenablog.com 本記事の章立てはこのようになります。 Proxy環境下でのインストール概要 インストール方法 インストール後の確認 対応する日本語ドキュメントは下記になります。 6.1.7.2. インストール時のクラスター全体のプロキシーの設定 Proxy環境下でのインストール概要 OpenShift 4.1では、インストールの時点から各ノードがインターネットへ接続できる必要がありました。 OpenShift 4.2からは新たにProxyのサポートが追加され、インストール時およびインストール後のクラスターから、Proxy経由でのインターネット通信が可能となりました。 主な用途はオンプレ環境にクラスタを配置するような場合で、インターネットへのアクセスにProxyの利用が必須な状況に対応が可能です。 Proxyの問題で躊躇していたような方も、これにより検証などが進めやすくなるのではないでしょうか。 Cluster-wide Proxy また、Proxyも無く、完全に制限された環境にクラスタを配置するオプションについてもOpenShift 4.2からサポートされます。これについては機会があれば別途解説できればと思います。 *2 インストール方法 では、Proxy環境下でのインストール方法について説明していきます。 前回の記事同様に、ベアメタルでのUPIインストールを例にします。 ※なお、現時点ではOpenShift 4.2はGAになっていないので、Developer Preview版を利用して説明します。 *3 インストール構成 今回利用する環境は、前回記事の環境に少し変更を加えました。 Proxyサーバーの追加 踏み台サーバーのNATをオフ *4 検証環境ネットワーク構成図 この環境では、 社内ネットワーク のルーターは、 検証用ネットワーク への戻りルートを知らないので、結果的に 検証用ネットワーク からはProxyサーバーを経由しないとインターネットへの接続が出来ない構成となっています。 *5 また、社内Proxyサーバーは、以下のような要件となっています。 Proxyはsquidで構成 HTTPおよびHTTPSは TCP:8080 で待ち受け。ただし、テスト時はHTTPまたはHTTPSどちらかのみに切り替えて実行。 *6 HTTPSはSSL Bumpで構成 ユーザー認証有り(ID: user/PASS: user) OSに 検証用ネットワーク への戻りルートを静的に追加 インストール設定ファイル UPIインストール方法自体は前回記事と同様です。 異なるのは、Proxy設定をインストール設定ファイル install-config.yaml に記載する点です。 設定する内容は下記の項目です。 proxy: httpProxy: http://<username>:<pswd>@<ip>:<port> httpsProxy: http://<username>:<pswd>@<ip>:<port> noProxy: example.com additionalTrustBundle: | -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- 必須項目は httpProxy です。 httpsProxy を省略した場合は、 httpProxy のみが使用されます。 URLスキーマは http:// のみサポート ユーザー認証がある場合は、IPアドレスの前に付与します。 noProxy には直接アクセスしたい宛先をカンマ区切りで記載します。ドメイン名やIPアドレス、ネットワークCIDRなどが使用できます。 additionalTrustBundle: SSLサーバー証明書の内容をここに記載します。 各設定は利用するProxyサーバーに合わせて変更してください。 HTTP、HTTPSでの設定例は下記の通りです。 HTTP場合 apiVersion: v1 baseDomain: example.local proxy: httpProxy: http://user:user@192.168.1.22:8080 noProxy: example.local compute: ... HTTPSの場合 apiVersion: v1 baseDomain: example.local proxy: httpProxy: http://user:user@192.168.1.22:8080 httpsProxy: http://user:user@192.168.1.22:8080 noProxy: example.local,172.16.0.0/24 additionalTrustBundle: | -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- compute: ... ※注意点。 noProxy に baseDomain を指定しておいた方が良いです。インストール後半で、クラスタからoauth-openshift、consoleへのルートへアクセスできず、authenticationとconsole operatorが起動しません。 HTTPSの場合、 noProxy に各ノードのIPアドレスまたはネットワークアドレスを指定する必要が有ります。インストール後半で、クラスタからoauth-openshiftへのアクセスでエラーになり、authentication operatorが起動しません。 エラー内容 WellKnownEndpointDegraded: failed to GET well-known https://172.16.0.101:6443/.well-known/oauth-authorization-server: x509: certificate signed by unknown authority additionalTrustBundle にSSLサーバー証明書をコピペした場合は、スペース（1つ以上）でインデントを行うこと。 インストールの実行 install-config.yaml 作成後の手順は通常と同じです。前回の記事を参考にしてください。 インストール開始後は、まずBootstrapノードが quay.io に接続します。トレースを行う場合は、まずはBootstrapノードが通信できているかどうかを確認してみてください。 参考に検証環境でのProxyサーバー（squid）のログを載せておきます。 HTTP接続時のログ 1570812044.098 920 172.16.0.100 TCP_TUNNEL/200 5591 CONNECT quay.io:443 user HIER_DIRECT/54.204.46.170 - 1570812044.938 839 172.16.0.100 TCP_TUNNEL/200 6820 CONNECT quay.io:443 user HIER_DIRECT/54.204.46.170 - 1570812045.753 814 172.16.0.100 TCP_TUNNEL/200 7239 CONNECT quay.io:443 user HIER_DIRECT/54.204.46.170 - 1570812046.572 816 172.16.0.100 TCP_TUNNEL/200 7509 CONNECT quay.io:443 user HIER_DIRECT/54.204.46.170 - 1570812047.479 906 172.16.0.100 TCP_TUNNEL/200 7139 CONNECT d3uo42mtx6z2cr.cloudfront.net:443 user HIER_DIRECT/99.86.193.123 - 1570812048.261 779 172.16.0.100 TCP_TUNNEL/200 7480 CONNECT quay.io:443 user HIER_DIRECT/54.204.46.170 - 1570812048.270 786 172.16.0.100 TCP_TUNNEL/200 7480 CONNECT quay.io:443 user HIER_DIRECT/54.204.46.170 - 1570812048.297 814 172.16.0.100 TCP_TUNNEL/200 7480 CONNECT quay.io:443 user HIER_DIRECT/54.204.46.170 - 1570812048.329 846 172.16.0.100 TCP_TUNNEL/200 7480 CONNECT quay.io:443 user HIER_DIRECT/54.204.46.170 - 1570812048.337 854 172.16.0.100 TCP_TUNNEL/200 7509 CONNECT quay.io:443 user HIER_DIRECT/54.204.46.170 - 1570812048.477 994 172.16.0.100 TCP_TUNNEL/200 7509 CONNECT quay.io:443 user HIER_DIRECT/54.204.46.170 - 1570812049.042 744 172.16.0.100 TCP_TUNNEL/200 7206 CONNECT d3uo42mtx6z2cr.cloudfront.net:443 user HIER_DIRECT/99.86.193.123 - 1570812049.671 1409 172.16.0.100 TCP_TUNNEL/200 515090 CONNECT d3uo42mtx6z2cr.cloudfront.net:443 user HIER_DIRECT/99.86.193.123 - 1570812050.595 2324 172.16.0.100 TCP_TUNNEL/200 4256164 CONNECT d3uo42mtx6z2cr.cloudfront.net:443 user HIER_DIRECT/99.86.193.123 - ... HTTPでSSLをトンネリングしていることが、ログ上の TCP_TUNNEL で確認できます HTTPS接続時のログ 1570907184.934 650 172.16.0.100 NONE/200 0 CONNECT quay.io:443 user HIER_DIRECT/23.23.158.172 - 1570907185.146 192 172.16.0.100 TCP_MISS/401 385 GET https://quay.io/v2/ user HIER_DIRECT/23.23.158.172 text/html 1570907185.738 591 172.16.0.100 NONE/200 0 CONNECT quay.io:443 user HIER_DIRECT/23.23.158.172 - 1570907185.996 254 172.16.0.100 TCP_MISS/200 1614 GET https://quay.io/v2/auth? user HIER_DIRECT/23.23.158.172 application/json 1570907186.622 625 172.16.0.100 NONE/200 0 CONNECT quay.io:443 user HIER_DIRECT/23.23.158.172 - 1570907186.867 241 172.16.0.100 TCP_MISS/200 2033 GET https://quay.io/v2/openshift-release-dev/ocp-release-nightly/manifests/sha256:75f065cf0590077ffba27ac61e104420660b8d2a344e09a11edd3cde50d14b01 user HIER_DIRECT/23.23.158.172 application/vnd.docker.distribution.manifest.v2+json 1570907187.457 588 172.16.0.100 NONE/200 0 CONNECT quay.io:443 user HIER_DIRECT/23.23.158.172 - 1570907187.709 245 172.16.0.100 TCP_MISS/302 2274 GET https://quay.io/v2/openshift-release-dev/ocp-release-nightly/blobs/sha256:5b7c299128e6dc655d47b57424e9cfde33585ed958ba5572ec1b184d5fb81866 user HIER_DIRECT/23.23.158.172 text/html 1570907187.829 119 172.16.0.100 NONE/200 0 CONNECT d3uo42mtx6z2cr.cloudfront.net:443 user HIER_DIRECT/13.224.151.231 - 1570907188.572 738 172.16.0.100 TCP_MISS/200 2125 GET https://d3uo42mtx6z2cr.cloudfront.net/sha256/5b/5b7c299128e6dc655d47b57424e9cfde33585ed958ba5572ec1b184d5fb81866? user HIER_DIRECT/13.224.151.231 binary/octet-stream 1570907189.148 572 172.16.0.100 NONE/200 0 CONNECT quay.io:443 user HIER_DIRECT/23.23.158.172 - 1570907189.153 577 172.16.0.100 NONE/200 0 CONNECT quay.io:443 user HIER_DIRECT/23.23.158.172 - 1570907189.159 584 172.16.0.100 NONE/200 0 CONNECT quay.io:443 user HIER_DIRECT/23.23.158.172 - ... GET https://〜 のログが確認できるので、ProxyサーバーからSSLで通信していることが分かります インストール後の確認 無事にクラスタが起動したら、下記の操作でインストール後の設定を確認してください。 HTTPの場合 # oc get proxy/cluster -o yaml apiVersion: config.openshift.io/v1 kind: Proxy metadata: creationTimestamp: "2019-10-11T16:44:26Z" generation: 1 name: cluster resourceVersion: "429" selfLink: /apis/config.openshift.io/v1/proxies/cluster uid: 634d22a2-ec46-11e9-a47f-000c29e26ff4 spec: httpProxy: http://user:user@192.168.1.22:8080 noProxy: example.local trustedCA: name: "" status: httpProxy: http://user:user@192.168.1.22:8080 noProxy: .cluster.local,.svc,10.0.0.0/16,10.128.0.0/14,127.0.0.1,172.30.0.0/16,api-int.test.example.local,api.test.example.local,etcd-0.test.example.local,etcd-1.test.example.local,etcd-2.test.example.local,example.local,localhost status: の noProxy に自動的にパラメーターが追加されているのが確認できます HTTPSの場合 # oc get proxy/cluster -o yaml apiVersion: config.openshift.io/v1 kind: Proxy metadata: creationTimestamp: "2019-10-12T19:12:15Z" generation: 1 name: cluster resourceVersion: "430" selfLink: /apis/config.openshift.io/v1/proxies/cluster uid: 33d1a475-ed24-11e9-96e7-000c29e26ff4 spec: httpProxy: http://user:user@192.168.1.22:8080 httpsProxy: http://user:user@192.168.1.22:8080 noProxy: example.local,172.16.0.0/24 trustedCA: name: user-ca-bundle status: httpProxy: http://user:user@192.168.1.22:8080 httpsProxy: http://user:user@192.168.1.22:8080 noProxy: .cluster.local,.svc,10.0.0.0/16,10.128.0.0/14,127.0.0.1,172.16.0.0/24,172.30.0.0/16,api-int.test.example.local,api.test.example.local,etcd-0.test.example.local,etcd-1.test.example.local,etcd-2.test.example.local,example.local,localhost status: の noProxy に自動的にパラメーターが追加されているのが確認できます trustedCA が user-ca-bundle で登録されていることが確認できます。 user-ca-bundle の詳細は下記のコマンドで確認できます。 # oc get cm/user-ca-bundle -n openshift-config -o yaml apiVersion: v1 data: ca-bundle.crt: | -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- kind: ConfigMap metadata: creationTimestamp: "2019-10-12T15:29:28Z" name: user-ca-bundle namespace: openshift-config resourceVersion: "279" selfLink: /api/v1/namespaces/openshift-config/configmaps/user-ca-bundle uid: 1448c4a4-ed05-11e9-8305-000c29e26ff4 GUIで確認する場合 Cluster Settings > Global Configration > Proxy で、YAMLを開くと同じ内容が確認できます。 また、インストール後にクラスタからProxyの通信が問題なく行えるか確認したい場合に簡単に確認する方法があります。 Cluster Settings > Overview で、Channelを他の物に切り替える度に通信が発生します。 Proxyサーバー側で下記ような通信ログを確認すると通信の有無が確認できます。 Channel切り替え 1570981786.525 567 172.16.0.101 NONE/200 0 CONNECT api.openshift.com:443 user HIER_DIRECT/18.215.44.164 - 1570981786.724 194 172.16.0.101 TCP_MISS/200 532 GET https://api.openshift.com/api/upgrades_info/v1/graph? user HIER_DIRECT/18.215.44.164 application/json まとめ OpenShift 4.2における、Proxy環境下でのインストールについては以上です。 インストール設定ファイルを少し変更するだけで対応できるので、非常に簡単です。Proxy環境でのOpenShift 4の導入を検討されている方は、是非手順を参考にトライしてみてください。 それでは初秋を感じながら、4.2 GAのリリースを今しばらくお待ちください！ Let's get Big Ideas ! *1 : Red Hat Japanには西日本支社 九州・中国営業所（通称:福岡オフィス）があります。最近一部屋増え、賑やかになってきました *2 : Disconnected “Air-gapped” Installについてはこちらも参考に。 https://docs.google.com/document/d/1cCnER-IMDCfinO7DiSvATt8WE4-YBngKrSb2aeBToZA/edit#heading=h.d6trypcglece *3 : 4.2.0-0.nightly-2019-10-07-203748を利用 *4 : # firewall-cmd --zone=trusted --remove-masquerade --permanent *5 : ACKが帰ってこず、タイムアウトに時間がかかりますが、今回の検証環境ではProxy無しで直接通信するようなシチュエーションは無いので、良しとしています *6 : Proxy設定で指定できるURLスキーマがhttp://のみなので、今回の検証環境では排他実行としています。通常のProxy運用では、実運用に合わせてProxy側を設定してください。

Red Hatの森若です。 RHEL独特のソフトウェアのひとつに、virt-who というものがあります。 virt-whoは購入したサブスクリプションを管理するための仕組みの一部で、2013年ごろに登場しました。 今回はこの紹介をします。なおスライド形式の資料をこの記事末尾に埋め込んでいます。 過去のサブスクリプション管理にあった課題 virt-whoが解決する課題を理解するために、virt-who以前の状況を見てみましょう。 Red Hat Enterprise LinuxをはじめとするRed Hat製品は、利用しているシステムの数を企業全体で数え上げて、必要なだけサブスクリプションを購入する契約になっています。 総数が足りていればよいので、2013年くらいまで主に使われていた古い仕組みでは、製品種別ごとにシステム登録数を数えあげ、所有しているサブスクリプションを積み上げた上限と比較する仕組み(Red Hat Network Classic)でした。登録されたシステムでは yum (またはup2date)によるパッケージ更新などが行えます。 物理サーバしかなかった頃にはこの方式で問題なかったのですが、1ホスト上で仮想マシンを多数動かせるようになると齟齬がでてきました。 RHELには「1ホスト上であれば仮想マシンを無制限に構築できる」というサブスクリプションがあります。当時はあまりうまい方法がなく、ゲスト数無制限のサブスクリプションを1本買うと、単純に登録できる仮想マシンが100システム増えるという非常におおざっぱな実装になっていました。 たとえばこの図のように、仮想化クラスタの物理サーバを当初2台で構築し、ハードウェアを1台増設したが該当するサブスクリプションを購入しない場合、契約違反になってしまいます。しかしVMの数を数えているだけでしたので警告すら発生しませんでした。 さらにSOX法やPCI-DSSなどを背景としてサブスクリプション管理(ライセンス管理)を厳密に行い、どのサブスクリプションとどのシステムが対応しているかを厳密に把握したいという顧客側のニーズもありました。 subscription-manager, virt-who, Red Hat Satellite 6登場 2013年にRHELの製品体系が変わり、その後従来より厳密な新しい管理方式(Red Hat Subscription Management)が登場しました。数年の移行期間を経たのち従来の仕組みは廃止され、現在では2020年5月にサポートが終了するRed Hat Satellite 5のユーザを例外として、全て新しい方式で提供されています。新しい管理方式では、subscription-manager で各システムをRed Hat Networkに登録し、virt-whoでハイパーバイザとゲストの対応づけを行います。 インターネット接続できないなどの理由でRed Hat Networkに接続できない場合には、同じサブスクリプション管理の仕組みを実装したRed Hat Satellite 6を導入します。 (登場直後は、サブスクリプション管理だけを行うRed Hat Subscription Asset Managementが提供されていましたが現在では廃止されています。) subscription-managerは全てのRHELシステム上で動作し、自分自身を登録します。一方virt-whoは、ハイパーバイザとゲストの対応関係を登録するので、どこに存在してもかまいません。 仮想マシンは複数のハイパーバイザ間を移動できますので、virt-whoは定期的に情報を取得・更新する必要があります。 virt-whoの設定や利用などに関連するドキュメント等 上記のような RHEL特有のニーズで作成されたものですので、virt-who自体はオープンソースなのですが、関連するドキュメントや知見はRed Hat Customer Portalに集中しています。 RHEL システム登録のスタートガイド >> 第6章 仮想マシンのサブスクリプションの設定 virt-whoが必要かどうかの確認や設定例、トラブルシュートなど仮想マシンを登録する際に必要になる情報がまとまっています。 Red Hat Virtualization Agent Configuration Helper ウィザード形式で virt-whoの設定を作成します virt-who FAQ集 yum updateなどを利用しない場合、virt-whoやsubscription-managerを利用してサブスクリプション管理をすることに価値はありますか? →ソフトウェアの機能としては特にありません。 契約を守るというコンプライアンスの観点で、知らない内に契約違反になってしまうリスクを回避できます。 資産管理の観点から、どの契約がどのシステムに対応しているかの対応を管理することができます。 virt-whoによる対応づけは必須ですか? →いいえ。契約上の必要本数以上サブスクリプションを購入していれば登録も対応づけも必須ではありません。 virt-whoによる対応づけをしないとどうなりますか? →24時間の猶予ののち、各仮想マシンは物理サーバ1台として扱われます。 そもそもシステムを登録しないことは可能ですか? → 可能です。インストールされたシステムに機能の制約などはありませんが、Customer PortalやSatelliteを利用するyum update等は利用できません。 virt-whoのために独立した仮想マシンは必要ですか? → 必須ではありません。virt-whoは他のサービスを利用しているシステムに同居できます。 お客様が「サービスを提供しているシステムはvCenterと直接通信できない」という運用ポリシーの場合に、別途構築するケースはあります。 virt-whoは対応付けに関連する仮想化環境上で動作する必要がありますか? → いいえ。virt-whoは仮想化環境およびサブスクリプション管理システムと適切に通信できればどこで動作してもかまいません。 インターネットに接続できません。どうしたらいいですか? →「システムを登録しない」「Red Hat Satelliteを構築しシステムを登録」の2とおりのオプションがあります virt-whoが動作する仮想マシンからvCenterなど仮想化環境の管理システムへの接続が社内ポリシーなどの都合でできません。どうしたらいいですか? → virt-whoを別途物理サーバ等で動作させることが可能です。 どこからも仮想化環境の管理システムに接続できない場合、対応できません。 サポート対象外の仮想化環境(Citrix XenServer, OracleVM, VirtualBox, VMware Fusionなど)でvirt-whoは動作しますか? → おそらくほとんどの場合に動作しませんがサポート対象外なので回答できません。 動作しなくて困ってもサポート対象外なのでサポート窓口へのお問いあわせもご遠慮ください。 契約上、無制限ゲストの型番を利用すること自体は可能です。ただし、上記のとおり動作しなくてもサポートすることができません。ご注意ください。

お疲れ様です！Red Hatの鈴木（tomosuzu）です！ 今回は「モブプログラミング」です。 以前、ペアプログラミングをご紹介しました。 ペアプログラミングが開発だとするならば、 モブプログラミングは学習です。 チーム全体に学習が必要な際に 取り入れみてはいかがでしょうか。 下記のリンクからご覧ください。 tomosuzu.com 次回は「バックログ・リファインメント」を紹介します。 さいごに Red Hatでは、「アイデアをイノベーションに変える、文化・プロセス・技術・実践の場」として、 Open Innovation Labs を提供しています。 デザイン思考やDevOps、アジャイルやリーン開発などをRed Hatのコンサルタントと一緒に取り組むことができます。 過去記事 アジャイル開発のプラクティス一覧をご紹介いたします - 赤帽エンジニアブログ チームの知識共有とコミュニケーションを増やします「ペアプログラミング 」 - 赤帽エンジニアブログ 速い開発速度を保ち、着実に開発を進める「テスト駆動開発」 - 赤帽エンジニアブログ チームの自律性・自主性を高める「社会契約」 - 赤帽エンジニアブログ チームの健康状態を知り、様々な問題に事前に対処「チーム感情の評価」 - 赤帽エンジニアブログ 改善のサイクルを小さく回す「ふりかえり」 - 赤帽エンジニアブログ 目標を明確にして、チームを集中させる「スプリント計画」 - 赤帽エンジニアブログ 機能ではなく、ビジネスゴールをデリバリする「インパクトマッピング」 - 赤帽エンジニアブログ チームを同期し、目標の認識強化「毎日のスタンドアップミーティング」 - 赤帽エンジニアブログ ユーザーを身近にし、認識を共有する「共感マッピング」 - 赤帽エンジニアブログ 作るものへの共通理解を生み出す「ユーザーストーリーマッピング」 - 赤帽エンジニアブログ プロセスの無駄を洗い出す「バリューストリーム・マッピングおよびプロセスマッピング」 - 赤帽エンジニアブログ

お久しぶりです。森 ( @mosuke5 ) です。 最近、韓国・中国と行く予定があり、世界のおもしろ体験をいろいろしてきました。 中でも中国の未来コンセプトのホテル(Flyzoo)やスーパーマーケット(Hema)などなど。こちらは話すと長くなってしまうので別の機会に。。 さて、本題ですが、会社のとあるハンズオンにてOpenShiftへのアプリケーションのデプロイをopenshift-applierというツールを使っているのを見かけたので気になって調べてみましたので軽くご紹介です。 github.com openshift-applierとはなにか openshift-applierは、OpenShiftのオブジェクトをクラスタにデプロイするためのAnsibleのRoleです。 Ansibleを使ってOpenShiftやKubernetesクラスタにリソースをデプロイするには、 k8sモジュール というのがもともと用意されており、こちらを使ってもできます。こちらについては以前に検証したことがありましたので下記参考にしてください。 blog.mosuke.tech openshift-applierでは、OpenShiftのテンプレート機能を使ってデプロイできる点やマニュフェストの適応の前後に任意の処理を入れられるなどがユニークなポイントです。OpenShiftを使ったことある方ならご存知かと思いますが、テンプレートという機能を使って、マニュフェストの一部のパラメータを変数化したり、複数のオブジェクトをまとめたりすることができます。（ 公式ドキュメントはこちら ） すごく簡単な例を示します。 Namesoaceを作るテンプレートです。Namespace名やそのDescriotionを変数化しています。 apiVersion : v1 kind : Template labels : template : projectrequest-template message : 'Project/Namespace has been created: ${NAMESPACE}' metadata : annotations : description : ProjectRequest Template creationTimestamp : null name : projectrequest-template objects : - apiVersion : v1 description : ${NAMESPACE_DESCRIPTION} displayName : ${NAMESPACE_DISPLAY_NAME} kind : ProjectRequest metadata : name : ${NAMESPACE} parameters : - description : Name displayName : Name name : NAMESPACE required : true - description : DisplayName displayName : DisplayName name : NAMESPACE_DISPLAY_NAME required : true - description : Description displayName : Description name : NAMESPACE_DESCRIPTION いくつかの項目が変数化されており、 oc process コマンド実行時にパラメータを渡すことで、マニュフェストを生成してくれます。 これをそのままクラスタにデプロイしたい場合は oc process xxxxxxx | oc apply -f - で引き渡すことも可能です。OpenShiftのドキュメントやチュートリアルなどを読んでいるとよく出てくるパターンですね。 $ oc process --local -f templates/project/project.yml -p NAMESPACE=hoge -p NAMESPACE_DISPLAY_NAME=hoge { "kind": "List", "apiVersion": "v1", "metadata": {}, "items": [ { "apiVersion": "project.openshift.io/v1", "description": "", "displayName": "hoge", "kind": "ProjectRequest", "metadata": { "labels": { "template": "projectrequest-template" }, "name": "hoge" } } ] } $ oc process --local -f templates/project/project.yml -p NAMESPACE=hoge -p NAMESPACE_DISPLAY_NAME=hoge | oc apply -f - なにがいいか 話が少しそれてしまいましたが、openshift-applierではこのOpenShiftのテンプレート機能などの展開が可能になりますが、このツールを使うとどんなメリットがあるかもう少し詳しく考えてみます。 1. テンプレート処理が利用できる まずはなんと言ってもOpenShiftのテンプレートの機能が使いやすいことでしょう。 OpenShiftでは、デフォルトでもいくつかのテンプレートを用意していて活用する場面はただあります。 テンプレートの処理がフレームワーク化されているのは便利と感じます。 また、OpenShiftのテンプレート機能に加えて、Ansibleで採用しているjinja2のテンプレートエンジンも併用して利用できます。 OpenShiftのテンプレート機能で表現しきれない部分をjinja2でテンプレート化することもできます。 2. 生成するリソースの順番を意識できる Kubernetesのリソースの扱いの中で、リソースの作成の順番を気にしたいケースがあります。 例えば、Namespaceは先に作っておいてほしいや、DBはアプリより先にデプロイしてほしいなどです。 openshift-applierではオブジェクトの順番を意識して記述することが可能です。 また、"pre/post steps"という機能もあり、特定のリソースの適応の前後に任意の処理を入れ込むことができます。 次のようなユースケースで有効です。 次の処理に行く前にリソースが立ち上がるまで待ちたい アプリケーションのデプロイ後に、サンプルデータや特定のデータを投入したい Deploymentにラベルや環境変数など追加の情報を適応したい openshift-applier/README.md at master · redhat-cop/openshift-applier · GitHub 3. ansible-vaultが利用できる そして、ansible-vaultと組み合わせて利用できること、これは便利と感じます。 Secretオブジェクトの中身のデータなどをansible-vaultで暗号化して管理しておき、デプロイ時に復号化して渡すことが可能です。 以下は、 Secretを作るときのサンプルですが、passwordという変数はansible-vaultで暗号化しておくことが可能です。 apiVersion: v1 data: password: {{ password | b64encode }} kind: Secret metadata: creationTimestamp: null name: mysecret 実際に試す方法 さて、実際に少し試してみようかなと思ったわけですが、なんとkatacodaで気軽に試せる環境を用意してくれています。 そのため、このブログでは手順などは割愛します。 www.katacoda.com 次世代のopenshift-applier 現在、openshift-applierはバージョン2なのですが、バージョン3では大きな変更を検討しているようです。 ”Dash”というプロジェクトネームで検討しているようですが、その設計方針で個人的に注目したポイントは下記です。 ※設計方針の案なので確定しているわけではありません。 Golang実装にしてCLI的に動かせるように kustomizeやhelmに対応 詳しいことが書かれているわけではないのですが、Golang実装にしてCLI的に利用できるようにしたいそうです。 また、テンプレート処理もOpenShiftのテンプレート機能とJinja2に加えて、kustomizeやHelmに対応していきたいとのことです。 Kubernetesを運用していくと、マニュフェストのテンプレートエンジン化が必要になってくることが多いです。 個人的にkustomizeというツールが使い勝手がよいと感じていてOpenShiftへの適応も試したりしていました。このあたりは興味深いポイントでした。 余談ですが、kustomizeについてはこちらを是非参考にしてください。 Kustomizeで環境ごとに異なるマニフェストを作る | Goldstine研究所 さいごに たまたまハンズオンで見かけたOSSのツールではありましたが、調べてみるといろいろと面白い発見がありました。 Kubernetes上でのアプリケーションの運用では、マニュフェストのテンプレートエンジン化とデプロイ制御について課題も感じていたところでした。 このあたりについてまた知見などたまれば投稿していきたいと思います。

お疲れ様です！Red Hatの鈴木（tomosuzu）です！ 今回は「バリューストリーム・マッピングおよびプロセスマッピング」です。 企画してから開発、リリースするまでにすごく時間がかかるけど 何が原因なのかわからない そんな時に有効なのが今回のプラクティスです。 顧客に価値を提供するまでにあるムダを洗い出すことができます。 下記のリンクからご覧ください。 tomosuzu.com 次回は「モブプログラミング」を紹介します。 さいごに Red Hatでは、「アイデアをイノベーションに変える、文化・プロセス・技術・実践の場」として、 Open Innovation Labs を提供しています。 デザイン思考やDevOps、アジャイルやリーン開発などをRed Hatのコンサルタントと一緒に取り組むことができます。 過去記事 アジャイル開発のプラクティス一覧をご紹介いたします - 赤帽エンジニアブログ チームの知識共有とコミュニケーションを増やします「ペアプログラミング 」 - 赤帽エンジニアブログ 速い開発速度を保ち、着実に開発を進める「テスト駆動開発」 - 赤帽エンジニアブログ チームの自律性・自主性を高める「社会契約」 - 赤帽エンジニアブログ チームの健康状態を知り、様々な問題に事前に対処「チーム感情の評価」 - 赤帽エンジニアブログ 改善のサイクルを小さく回す「ふりかえり」 - 赤帽エンジニアブログ 目標を明確にして、チームを集中させる「スプリント計画」 - 赤帽エンジニアブログ 機能ではなく、ビジネスゴールをデリバリする「インパクトマッピング」 - 赤帽エンジニアブログ チームを同期し、目標の認識強化「毎日のスタンドアップミーティング」 - 赤帽エンジニアブログ ユーザーを身近にし、認識を共有する「共感マッピング」 - 赤帽エンジニアブログ 作るものへの共通理解を生み出す「ユーザーストーリーマッピング」 - 赤帽エンジニアブログ

こんにちは、レッドハットの中村です。9月23日〜26日に開催されていたAnsibleFest 2019 in Atlantaにて、レッドハットから Ansible Automation Platformが発表されました 。詳細情報はこれから出てくると思いますが、簡単に発表された内容をまとめておきたいと思います。 1日目の基調講演にてレッドハットのSenior Principle Product Managerである、Richard Henshall から概要が発表され、2日目の基調講演のデモセッションで実際の画面を紹介されました。 Ansible Automation Platform Richard Henshalの講演内容 以下に簡単に彼の講演した内容をスクリプトっぽく書いていきます。 ーーーはじまりーーー Ansibleはその簡易性から、自動化することを簡単にし、様々な人や組織の自動化を実現させてきた。簡単にシェアすることができ、スケールさせ、スキルアップを簡単にすることができることが、Ansibleをクリティカルマスまで持ち上げてきた。 自動化するにあたって課題になるのが、他人へどのように動機づけることができるか、である。自動化の価値を示せば、動機づけすることができるのではないか。 このように、Ansibleによる自動化は、Task-based Automation （注：タスクを自動化する活動） からAutomation Strategy （注：自動化についての戦略的取り組み） に変化してきており、自動化は簡単に浸透するものの、その後組織内で調整が必要になるため、そこに対してどのように向かい合うかという問題が生じる。自動化に関する強力は勝手に進むが、組織間で目標値をすり合わせる必要があったりする。 （注：その調整などの摩擦を軽減するために） Ansible Automation Platform（以下、Platformと略）を発表。Platformは、Ansibleを使うにあたっての、Create、Scale、Engageを支援する価値を提供する。3つの要素は以下の通り。 Ansible Automation Platformの全体像 ーーーおわりーーー Ansible Automation Platform、3つの要素 Create：Ansible Engineのレイヤー。共通的な自動化言語としてAnsible Playbookを活用する。 Scale：Ansible Towerのレイヤー。運用を容易かつセキュアにし、大規模な環境でもコントロールができる。 Engage：ここが新しいレイヤー。いくつか要素があるので詳細を以下に記載する。 Ansible Platformの発表による新しい要素 Ansible Collections ：Role/Module/Plug-inなどの一覧。Collectionsにより、それらの情報を管理し、組織内に展開できるようにする。これにより、安定性と新しいコンテンツとのバランスがとれるようになる。Ansibleで実行されるPlaybookなどの維持管理に活用ができる。認定されたModuleなどのフィルターもここで見える化することが可能。 Automation Hub ：Ansible Galaxyをアップストリーム（開発の上流）として、Automatino Hubはダウンストリーム（安定して使える品質のもの）としてPlatform内で提供。Ansibleのサブスクリプションを購入しているユーザーはすぐにこれをダウンロードすることが可能になる。現状はCollectionsが閲覧することができる。ここで、承認されたコンテンツを閲覧し、利用することが可能。 Automation Analytics ：Ansible Towerから実行された履歴をモニタリングすることができる。どの組織がどれくらいPlaybookを実行したかなどのメトリックがとれる。cloud.redhat.comから利用が可能。 Content ：ネットワークやセキュリティ自動化などのコンテンツを利用することが可能。CollectionでこのContentを確認することができる。現在は、Microsoft、Google Cloud、Cisco、F5、NetApp、Arista、Aruba、CheckPoint、CyberArk、DELL/EMC、Dynatrace、Fortinet、Purestorage、Rubrik、Sensu、XLAB StreampunkなどがContentとして登録されている。 Improved Execution：Ansible Towerのパフォーマンス改善を行っており、OpenShift上（コンテナ上）でスケールさせることが可能になってくる。 Automation Hub、Collection、Job Workflowのデモ 2日目の基調講演では、デモにより、Ansible Automation Platformの主要な要素である、Automation HubとCollectionsと、Ansible Towerの連携の模様が紹介された。コメディ風で笑いの耐えないデモで楽しく理解することができた。 デモの様子。バナナを電話子機のように使っているｗ デモの概要としては、インフラ、セキュリティ、アプリ開発の3つの部署の担当者が連携しながら、新しいアプリケーションをリリースしようとしているという内容（だったと思う。英語力‥）。 まずはインフラ担当者が、その問題について上司から伝えられ、まずはインフラの払い出しをするためのPlaybookをAnsible TowerのJob Workflow機能上に実装。 その後、セキュリティチーム担当の人へパスされ、セキュリティ設定をながすPlaybookを実装し、アプリ開発チームにパス。ロードバランサーの実装が必要なので、Automation HubのCollectionからF5のロードバランサーのContentを選択して実装。その際に別の部署と電話でやり取りしながら調整をする。 こんな感じのデモシナリオでした。 実際に、Automtion HubにてCollectionを確認する画面は以下のような形。もっと細かい情報が閲覧できると思う（例えば、これは認定されたModuleであるとか、承認済みModuleだとか）。 Automation HubからCollectionを閲覧するの図 また、Workflowは徐々に実装されていって、以下のような画面になった。文字が潰れているが、デモが進むに従って、右側にWorkflowが伸びていく感じで、実装されていく。チーム間で権限など違うのだろうけど、Workflow上への実装がリアルタイムなやり取りでされていってこれが理想像なのだろうと思った。 Job Workflow Analytics機能の画面は1日目のRichardのセッションにて簡単に紹介されていた。 Analytics 終わりに AnsibleFest オープニング動画！ かっくいー #ansiblefest pic.twitter.com/EZCVT0WOb4 — なかむらまこと @ 極度自動化(しなさい) (@fideleruuth) September 24, 2019 AnsibleFestは1500人近くの登録があり、日本からも20名前後参加していました。3日間、Ansibleづくしで、セッションによっては満席で座れないほどのセッションもあり、グローバルでもAnsibleの勢いを感じました。僕は事例関連のセッションを聞きましたので、できればブログにも情報を展開していこうと思っています。 また、Ansible Automation Platformについてはまだ詳細をキャッチアップできていませんので、今後ブログなどで紹介していきたいと思います。なお、これらの機能はすでにAnsible Automation（旧称）のサブスクリプションをご購入のお客様はすぐに使えるようですので、ぜひ試してみてください。 ※Disclaimer：速報記事のため、内容に多少の誤りがある可能性があります。詳細情報については、レッドハットまでお問い合わせください。

まいど。レッドハットでストレージを中心にクラウドインフラを生業にしている宇都宮です。 Rook 1.1 がリリースされました。色々なアップデートがありますが、Ceph-CSIがproduction-readyで対応したことからCephにとって大きな一歩になるでしょう。 さて 前回 は、Rook-Cephで障害を起こしてみてアプリに与える影響がどんなもんかを見てみました。今回はちょっと座学的になりますがRook-Ceph CSIの紹介とアーキテクチャのお話しをしたいと思います。 去る9/11(水)に OpenShift Meetup #6 が開催されました。雷雲うごめく中お越しいただいた皆様、ご登壇くださった皆様、本当にありがとうございました！ そしてもう次回の OpenShift Meetup #7 の情報が公開されています。注目のService MeshとServerless特集です！Twitter枠は空きがありますし、名古屋、大阪、福岡のサテライト会場でもLive中継されまーす！ OpenShift Meetup #5の セッション動画 がcrash.academyさんで公開されています。Operatorガチな方々のセッションをご覧下さい！ あとRookとOpenShift Japan CommunityのTwitterアカウントがあります。@japan_rookと@openshiftjpです。フォローお願いします！ 以上宣伝でした！ CSI : Container Storage Interface はいそれでは本題に入ります。Rook-Ceph CSIをご紹介しますがその前にCSIってナンダ？というお話です。 CSIって何よ CSIはKubernetes以外にもMesosとかCloudFoundryとかいろんなコンテナオーケストレーターシステム(COs)から、いろんなストレージを使えるように標準化されたストレージ管理APIです。 CSIがあることでユーザーはストレージに縛られることなくCOを選ぶことができるし、ストレージプロバイダはCO毎にドライバーを作ってメンテしなくて済みます。また、CSIはCOのコアの部分から隔離される形で実装されます。よってCOの開発側としてはコアの部分に謎のドライバロジックを埋め込むリスクもなくなりますし、ストレージのドライバ部分はテストしなくて済みます。 三方良しなアーキテクチャとして前々から必要性は言及されていたのですが、Kubernetesではv1.13でCSI 1.0がGAになりました。 こちらの通り 、色んなストレージプロバイダがCSI driverをリリースしています。 ちなみにKubernetesでは"in-tree plugin"と呼ばれる、Kubernetesのバイナリに組み込まれているストレージのドライバーが何種類かありますが、これら"in-tree"なドライバーは全てCSIに置き換えられるようになります。 "ストレージ CSI"でWeb検索するとたくさん記事が出てくるので、合わせて見てもらうとより理解が深まると思います。 Container Storage Interfaceのざっくりした図 Rook-Cephのアーキテクチャ よく見るRook-Cephのアーキテクチャ Web検索で"Rook Ceph"とかで画像検索すると、こんな図をよく見ることができます。 Rook-Ceph Architecture まあ確かにこうなんやけど、、、具体的にデプロイした姿を見ればより理解が深まると思います。というわけで実際にRook-Cephデプロイして見てみましょう。なんと今回はCSI仕様です。ババーン。 Rook 1.1でCephをデプロイしてみよう ではさっそく最新のRook 1.1を使ってRook-Cephを見てみましょう。今回はこんな6ノードのk8sクラスタを使います。worker nodeにそれぞれ10GBのEBSを1個ずつ付けてます。 [utubo@tutsunom ~]$ kubectl get node -L nodetype --sort-by='{.metadata.creationTimestamp}' NAME STATUS ROLES AGE VERSION NODETYPE ip-172-20-117-198.ec2.internal Ready master 32m v1.15.3 ip-172-20-37-240.ec2.internal Ready master 26m v1.15.3 ip-172-20-86-56.ec2.internal Ready master 19m v1.15.3 ip-172-20-70-151.ec2.internal Ready node 14m v1.15.3 ip-172-20-54-38.ec2.internal Ready node 7m41s v1.15.3 ip-172-20-121-163.ec2.internal Ready node 2m12s v1.15.3 あいにくOperatorHubのRook-Cephはまだ1.1じゃないんで、 github からインストールします。 *コマンド出力省略 [utubo@tutsunom ~]$ git clone https://github.com/rook/rook.git [utubo@tutsunom ~]$ cd rook/cluster/examples/kubernetes/ceph [utubo@tutsunom ceph]$ kubectl create -f common.yaml [utubo@tutsunom ceph]$ kubectl create -f operator.yaml [utubo@tutsunom ceph]$ kubectl create -f cluster.yaml これで終わりですよ。やっぱ簡単だなぁ。幸せだなぁ。ぼかぁ君と居ると(略 5,6分コトコト煮込んでいると自動的にCephクラスタができてます。 kubectl get all で見てみましょう。 [utubo@tutsunom ceph]$ kubectl get all -n rook-ceph NAME READY STATUS RESTARTS AGE pod/csi-cephfsplugin-87xc7 3/3 Running 0 3m43s pod/csi-cephfsplugin-j9dhm 3/3 Running 0 3m43s pod/csi-cephfsplugin-provisioner-68b89bfd6c-ms22r 4/4 Running 0 3m43s pod/csi-cephfsplugin-provisioner-68b89bfd6c-nc6q6 4/4 Running 0 3m43s pod/csi-cephfsplugin-slvzj 3/3 Running 0 3m43s pod/csi-rbdplugin-4ftsw 3/3 Running 0 3m43s pod/csi-rbdplugin-d4plf 3/3 Running 0 3m43s pod/csi-rbdplugin-dghcl 3/3 Running 0 3m43s pod/csi-rbdplugin-provisioner-669fdd7465-4fjj2 5/5 Running 0 3m43s pod/csi-rbdplugin-provisioner-669fdd7465-d452m 5/5 Running 0 3m43s pod/rook-ceph-mgr-a-f4d9d7c66-qgqxt 1/1 Running 0 2m19s pod/rook-ceph-mon-a-6986bcb454-thb5x 1/1 Running 0 2m57s pod/rook-ceph-mon-b-8974d98f9-gxgnj 1/1 Running 0 2m48s pod/rook-ceph-mon-c-6957d6db48-5tp5j 1/1 Running 0 2m33s pod/rook-ceph-operator-54665977bf-8kqqs 1/1 Running 0 5m8s pod/rook-ceph-osd-0-5d4ff9f46d-cf8mj 1/1 Running 0 79s pod/rook-ceph-osd-1-5479f66fc9-xwgk9 1/1 Running 0 78s pod/rook-ceph-osd-2-77464c5648-shgtl 1/1 Running 0 78s pod/rook-ceph-osd-prepare-ip-172-20-121-163.ec2.internal-cntf7 0/1 Completed 0 114s pod/rook-ceph-osd-prepare-ip-172-20-54-38.ec2.internal-c42bz 0/1 Completed 0 114s pod/rook-ceph-osd-prepare-ip-172-20-70-151.ec2.internal-65s66 0/1 Completed 0 114s pod/rook-discover-9vx4z 1/1 Running 0 5m7s pod/rook-discover-gdsn7 1/1 Running 0 5m7s pod/rook-discover-psnz5 1/1 Running 0 5m7s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/csi-cephfsplugin-metrics ClusterIP 100.64.60.214 <none> 8080/TCP,8081/TCP 3m44s service/csi-rbdplugin-metrics ClusterIP 100.65.62.154 <none> 8080/TCP,8081/TCP 3m44s service/rook-ceph-mgr ClusterIP 100.71.205.11 <none> 9283/TCP 115s service/rook-ceph-mgr-dashboard ClusterIP 100.69.192.148 <none> 8443/TCP 116s service/rook-ceph-mon-a ClusterIP 100.70.114.174 <none> 6789/TCP,3300/TCP 2m58s service/rook-ceph-mon-b ClusterIP 100.70.177.170 <none> 6789/TCP,3300/TCP 2m51s service/rook-ceph-mon-c ClusterIP 100.67.165.255 <none> 6789/TCP,3300/TCP 2m39s NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/csi-cephfsplugin 3 3 3 3 3 <none> 3m44s daemonset.apps/csi-rbdplugin 3 3 3 3 3 <none> 3m44s daemonset.apps/rook-discover 3 3 3 3 3 <none> 5m8s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/csi-cephfsplugin-provisioner 2/2 2 2 3m44s deployment.apps/csi-rbdplugin-provisioner 2/2 2 2 3m44s deployment.apps/rook-ceph-mgr-a 1/1 1 1 2m20s deployment.apps/rook-ceph-mon-a 1/1 1 1 2m58s deployment.apps/rook-ceph-mon-b 1/1 1 1 2m49s deployment.apps/rook-ceph-mon-c 1/1 1 1 2m34s deployment.apps/rook-ceph-operator 1/1 1 1 5m9s deployment.apps/rook-ceph-osd-0 1/1 1 1 80s deployment.apps/rook-ceph-osd-1 1/1 1 1 79s deployment.apps/rook-ceph-osd-2 1/1 1 1 79s NAME DESIRED CURRENT READY AGE replicaset.apps/csi-cephfsplugin-provisioner-68b89bfd6c 2 2 2 3m44s replicaset.apps/csi-rbdplugin-provisioner-669fdd7465 2 2 2 3m44s replicaset.apps/rook-ceph-mgr-a-f4d9d7c66 1 1 1 2m20s replicaset.apps/rook-ceph-mon-a-6986bcb454 1 1 1 2m58s replicaset.apps/rook-ceph-mon-b-8974d98f9 1 1 1 2m49s replicaset.apps/rook-ceph-mon-c-6957d6db48 1 1 1 2m34s replicaset.apps/rook-ceph-operator-54665977bf 1 1 1 5m9s replicaset.apps/rook-ceph-osd-0-5d4ff9f46d 1 1 1 80s replicaset.apps/rook-ceph-osd-1-5479f66fc9 1 1 1 79s replicaset.apps/rook-ceph-osd-2-77464c5648 1 1 1 79s NAME COMPLETIONS DURATION AGE job.batch/rook-ceph-osd-prepare-ip-172-20-121-163.ec2.internal 1/1 36s 116s job.batch/rook-ceph-osd-prepare-ip-172-20-54-38.ec2.internal 1/1 37s 116s job.batch/rook-ceph-osd-prepare-ip-172-20-70-151.ec2.internal 1/1 36s 116s おや、前回までの出力と違いますね。 - csi-cephfsplugin とか csi-rbdplugin-provisioner とか、CSIドライバーっぽいのができてる - rook-ceph-agent が無い そうなんです。1.1からRook-CephはCSIがデフォルトのドライバになります。だから特にCSI絡みのマニフェストファイルを kubectl create しなくてもCSIドライバーのPodが入るようになっています。 そして、 rook-ceph-agent が無いのも実はこれに関連しています。 rook-ceph-agent はFlexVolumeというストレージドライバで、worker nodeがCephのストレージをattachしたりmountしたりして使うために必要なドライバの役割を果たしていました。CSIがデフォルトになるまではFlexVolumeがデフォルトだったんですが、1.1からそれが逆転したので rook-ceph-agent はいなくなりました。 ちなみにFlexVolumeはまだサポートされるので、operatorをデプロイするマニフェストファイルでFlexVolumeをEnableにすると、 rook-ceph-agent はプロビジョンされます。 Podの配置を絵で見てみよう 割と結構な数のPodがたくさんあってごちゃごちゃしていますが、絵にするとこんな風になっています。 Rook-Ceph CSI Pods Podは大きくわけてRook, Ceph, Ceph CSIの3種類に群に分かれます。ガイア、マッシュ、オルテガと名付けるのはさすがに無理がありますが、こいつらのジェットストリームアタックによってアプリケーションにPVを提供するわけですね。はい。 ざっくり説明します。 Rook rook-ceph-operator Rook-Ceph Operatorそのもの。 rook-discover worker nodeに接続されるストレージデバイスをリアルタイムに検知する。Cephクラスタが稼働中にノードにデバイスを挿すと、discoverにより自動的に認識されるが、その後Operatorが定義されているルールに則してCephクラスタに新規osdとして追加するかしないか決める。 Ceph rook-ceph-mon Cephクラスタ全体を監視する。"MONitor"。障害等によるトポロジーの変化を察知し望ましい姿への復帰(下がった冗長性の復旧など)を司る。ユーザ認証も担う。 rook-ceph-osd Cephクラスタの保存媒体であるデバイスを抽象化した姿。"Object Store Device/Daemon"(諸説あり)。通常1デバイス=1osdの対応。Cephの全てのデータはosdによってデバイスに読み書きされる。 rook-ceph-mgr : Cephクラスターの管理面を担う。"ManaGeR"。Dashboardを提供したり、Prometheus,Zabbixなど外部ツールへのAPIを提供したりする。 Ceph CSI Ceph CSIのPodに注目してみましょう。 csi-rbdplugin , csi-cephfsplugin csi-rbdplugin-provisioner , csi-cephfsplugin-provisioner というのがあります。 前者はApp PodがCeph RBD/CephFSのPVを使うためのドライバで、全てのworker nodeにプロビジョンされます。 後者はざっくり言えばmasterのkube-apiserverに飛んできたCeph RBD/CephFS PV関連のリクエストをwatchして、飛んできたらストレージシステムに対してトリガーするという仲介役と捉えればOKです。 絵の右側の通り、どのPodも複数のコンテナで構成されていますが、この中でオレンジのコンテナはKubernetesの開発側から共通で提供されていて、グリーンのコンテナはストレージプロバイダーが独自に開発して提供するものです。例えば cis-rbdplugin-provisioner を覗いてみましょう。 [utubo@tutsunom ceph]$ kubectl get pod csi-rbdplugin-provisioner-669fdd7465-4fjj2 -o json | jq -r '.status.containerStatuses[] | .name, .image' | xargs -n2 csi-provisioner quay.io/k8scsi/csi-provisioner:v1.3.0 csi-rbdplugin quay.io/cephcsi/cephcsi:v1.2.0 csi-rbdplugin-attacher quay.io/k8scsi/csi-attacher:v1.2.0 csi-snapshotter quay.io/k8scsi/csi-snapshotter:v1.2.0 liveness-prometheus quay.io/cephcsi/cephcsi:v1.2.0 5つコンテナがあるんですが、 csi-provisioner , csi-rbdplugin-attacher , csi-rbdplugin-attacher は quay.io/k8scsi/ からpullしていて、 csi-rbdplugin , liveness-prometheus は quay.io/cephcsi/ からpullしてることがわかります。 ストレージプロバイダーはオレンジのsidecarの仕様に合わせて、緑色のコンテナイメージだけを開発・メンテすることになります。kubernetesの中身には一切手を付けないようになっているので、ドライバの修正やアップデートをしやすくなっていますね。 これらのPodが具体的にどんな動きをするのかは、 OpenShift Meetup #6 のサイトにアップされている資料で何となくうかがい知ることができますので、よかったら見てみて下さい。 まとめ そういうわけで今回は最新のRook 1.1でRook-Ceph CSIをデプロイしたときのアーキテクチャを紹介しました。何だかいろいろとできていないことがある気がするんですが、今回はここまで。

ご存知の方もいらっしゃると思いますが、Katacodaというサイトで簡単にAnsibleを試すことができます。これからAnsibleを入門、学習する方はもちろん、Ansibleを使ったことのない人に普及したい人もこちらを知らない人にお伝えいただくと仲間が増えるかと思います。以下では、 @Irix_jp さんが作成したKatacodaでの学習コンテンツの使いかたをご紹介いたします。 (1) https://www.katacoda.com/irixjp/ にアクセスする Ansible 101 の 「Start Scenario」をクリックする (2) 任意の方法でログインする GitHub、Facebook、Twitter、Googleなどのアカウントでログインすることが可能です。 ログインが求められるので、お好きな方法でログイン。 (3) ブラウザベースで教材通り進めてみましょう！ Start Scenarioをクリック 左に教材、右側にターミナルが表示されます。 おわりに Katacoda便利ですね！自社や自分のPCでAnsibleを使える環境を準備するのがちょっと面倒くさいということもあるかと思います。そんな場合には、ぜひこのKatacodaの教材を使って学習してみましょう！ また、レッドハットが運営を支援している Ansibleユーザー会では、このKatacodaと同じような環境を提供してもくもく学習していただく機会を提供しています。ネットワーク編なども学習することが可能ですので、もう一歩前進したい方はぜひご参加ください（初学者も大歓迎です）。 最後に、この教材について最近宣伝してくれている方が出てきているので、スライドを公開します（ こちら ）。ぜひ社内・社外への宣伝にご利用いただければと思います。 宣伝スライド 【宣伝】 Ansibleの日本語キャンペーンページでは英語のブログ記事などを翻訳し掲載していたりしますので、ぜひ一度御覧ください。 www.redhat.com

Red Hatの森若です。 以前、以下の記事で https://lab.redhat.com を紹介しました。利用はめちゃくちゃ簡単なのですが、メッセージが英語なのでまだすこし面倒なところがありました。 rheb.hatenablog.com 「Just Do It!」おじさんに励まされつつ このラボの一部を和訳しました。上記ページのカタログには掲載されていませんが、以下のリンクをクリックすると和訳されたラボがでてきて試せます。 bit.ly これらはkatacodaを利用したRHEL8の新機能を試すラボで、左側のテキストにそって操作することで、簡単にRHEL8の新機能を試すことができます。テキストを無視していろいろいじることもできます。 :-D 今度こそ非常に手軽に試せますのでぜひ触ってみてください!

前回の記事に引き続き、今回は、Tech PreviewとなったKnative ServingをOpenShift 4にインストールしてみます。ServiceMesh(Istio)がインストールされている環境が前提になるので、 こちらの記事 を読んでServiceMeshをインストールしてみてください。 今回もUIは使わずにCLIでインストールをしますが、Web UIからインストールする方は、1つ注意が必要です。現在(9月13日時点)、OperatorHubで「knative」と入力すると、Knativeのアイコンが検索結果に見つかります。 この「Knative Serving Operator」というOperatorは近々廃止される古いOperatorで、「Serverelss Operator」という名前のOperatorをインストールする必要があります。スクリーンショットを貼っておきますが、Red HatアイコンもKnativeアイコンに変えられる可能性もあるので、「Serverelss Operator」という名前のオペレーターをインストールすることを忘れないでください。 「Serverless Operator」をインストールする CLIでServerless Operatorをインストールする場合、コマンドは次のようになります。まず、CatalogSourceConfigとSubscriptionを作成します。 cat <<-EOF | oc apply -f - apiVersion: operators.coreos.com/v1 kind: CatalogSourceConfig metadata: name: serverless-operator namespace: openshift-marketplace spec: targetNamespace: openshift-operators packages: serverless-operator source: redhat-operators --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: serverless-operator-sub generateName: serverless-operator- namespace: openshift-operators spec: source: serverless-operator sourceNamespace: openshift-operators name: serverless-operator channel: techpreview EOF openshift-operatorsプロジェクトに、knative-openshift-ingressとknative-serving-operatorというOperatorが2つ起動すればOKです。 $ oc get pod -n openshift-operators NAME READY STATUS RESTARTS AGE elasticsearch-operator-6c44487696-nr42q 1/1 Running 0 14m istio-node-65vsl 1/1 Running 0 13m istio-node-8mr9b 1/1 Running 0 13m istio-node-b74b9 1/1 Running 0 13m istio-node-crpt2 1/1 Running 0 13m istio-node-krp8d 1/1 Running 0 13m istio-node-nftnj 1/1 Running 0 13m istio-operator-64f969655b-xhf7j 1/1 Running 0 14m jaeger-operator-55f47cccbc-f55rl 1/1 Running 0 14m kiali-operator-865b8cfc7b-nv8h5 1/1 Running 0 14m knative-openshift-ingress-55bdd6b797-mdgjj 1/1 Running 0 20s knative-serving-operator-d5fd5f444-hpsbg 1/1 Running 0 20s 以上で、Operatorのインストールはおしまいです。あとは、knative servingのサービス群を knative-serving プロジェクトに作成します。 oc new-project knative-serving cat <<-EOF | oc apply -f - apiVersion: serving.knative.dev/v1alpha1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving EOF コマンドを実行すると、今度は、 knative-serving プロジェクトにknative servingのPodが起動します。 oc get ks -n knative-serving が、READY状態になっていることも確認しておきます。 $ oc get pod -n knative-serving NAME READY STATUS RESTARTS AGE activator-78464cc84-pqpgn 1 / 1 Running 0 5m39s autoscaler-57479674d6-sp6s6 1 / 1 Running 0 5m38s controller-6fcb5b4b78-gwpwf 1 / 1 Running 0 5m33s networking-certmanager-8c6d68d4-nmxbg 1 / 1 Running 0 5m33s networking-istio-644984496f-fw4cm 1 / 1 Running 0 5m32s webhook-84b96fdc6f-d2vh4 1 / 1 Running 0 5m32s $ oc get ks -n knative-serving NAME VERSION READY REASON knative-serving 0 . 7 . 1 True また、 knative-serving プロジェクトとKnativeアプリをデプロイするプロジェクト(今回は demo という名前を使っています)を members に加えた ServiceMeshMemberRoll を作成します。 cat <<EOF | oc apply -f - apiVersion: maistra.io/v1 kind: ServiceMeshMemberRoll metadata: name: default namespace: istio-system spec: members: - knative-serving - demo EOF 以上で、インストールはおしまいです。やはり、OpenShift 4のOperatorはインストールが簡単です。せっかくなので、今回はKnativeアプリのデプロイまで試してみます。 oc new-project demo cat <<EOF | oc apply -f - apiVersion: serving.knative.dev/v1alpha1 # Current version of Knative kind: Service metadata: name: helloworld-go # The name of the app spec: template: spec: containers: - image: gcr.io/knative-samples/helloworld-go # The URL to the image of the app env: - name: TARGET # The environment variable printed out by the sample app value: "Go Sample v1" resources: limits: cpu: 10m requests: cpu: 10m EOF oc get ksvc でREADY状態になれば、デプロイ完了です。 $ oc get ksvc NAME URL LATESTCREATED LATESTREADY READY REASON helloworld-go http://helloworld-go.demo.apps.something.example.com helloworld-go-gccd5 helloworld-go-gccd5 True URL に出力されているURLにアクセスしてみましょう。 Hello Go Sample v1! と表示されました。 $ curl http://helloworld-go.demo.apps.something.example.com Hello Go Sample v1! しばらくするとhellworld-go Podが、Pod数「0」にスケールダウンされますが、URLにアクセスするとPodが起動し正常にアクセスを受け付けます。 $ oc get pod NAME READY STATUS RESTARTS AGE helloworld-go-gccd5-deployment-74b7ff8658-2vrbs 1/2 Terminating 0 5m18s $ oc get pod No resources found. Knative Servingは、この他にもIstioのネットワークを利用したトラフィックの分割やオートスケール、アプリケーションのリビジョン管理など、多くの機能があります。今回も、記事の説明が少ないし、「やってみた(だけ)」記事だし、Knativeインストールして、この後どうすれば良いか分からない、という方！次回の「OpenShift Meetup Tokyo」は、Service Mesh & Serverless 特集です。ぜひ、参加して更なる深い話を聞いたり、参加者で情報を共有しましょう。 openshift.connpass.com