こんにちは、Red Hatでストレージを中心にクラウドインフラを生業にしている宇都宮です。 今回から、Kubernetes(k8s)におけるストレージという 狭ーい ちょびっと深ーい話を連続で紹介します。 ご存知の方も多いと思いますが、k8sにはPersistent Volume(PV)という無敵に素敵なストレージ抽象化の仕組みがあります。だからアプリケーションからボリュームを使えるようにする辺りの処理に関してはほとんど考えなくて大丈夫。 じゃあバックエンドのストレージ自身はどうあるべきか？みたいな話って、あんまりされないんじゃないかなって思ってます。それは、k8sには多くの外部ストレージに対応したvolume driverやpluginがあって、既存の外部ストレージをそのままPVとして使えるから。実際には外部ストレージによってできる事できない事は色々ありますが、「今あるストレージが使えるんなら基本それでええやん」ってなる事情が多いんじゃないかなと。 だがしかし、世の中には「バックエンドストレージもk8s上で動かそうや」というとんがった考え方もあるんです。"Cloud-Native Storage"とか"Container-Native Storage"とか呼ばれたりします。 これはk8s上でPodとしてSDSを動かすんですが、まじめにPodでSDSをデプロイしたり運用したりするのは、冗長性とかデータインテグリティとか拡張性とか、色々考えなきゃならなくて結構大変。 だから、Cloud-Native Storageの運用構築をサポートするためのツールが生み出されてるんですね。Cloud-Native Storage専用ツールですよ。狭くてステキ！とがり過ぎ！キレッキレ！ というわけで、今日も前置き長くなりましたが、k8sやOpenShiftでSDSをオーケストレートするツールを紹介します。Rookです。 デカいねロゴが Rookってなに Rookは一言で言えば、k8s向けのストレージオーケストレーターです。Rookを使うことでk8s上にCephやEdgeFSなどのSDSを複数のPodとして起動して冗長化されたストレージ構成を作ることができます。 ここまでだと普通のインストーラーなんですが、 Rookは運用まで自動化してお手伝いしてくれるんです。 これについてはまた後ほど。 ご多分に漏れず、Rookはオープンソースソフトウェアです。ポータルサイトの rook.io から様々な情報を調べることができます。また、 github にリポジトリが公開されていて、誰でもお気軽に使えるし、開発に参加できます。 rook.io github.com Operatorとして自律的なストレージを提供 Rookはオーケストレーターというだけあって、ありとあらゆる事に目を配って面倒みてくれます。次のような作業を自動的に行う仕組みを持っていて、self-managing, self-scaling, self-healing なストレージを実現します。 deployment bootstrapping configuration provisioning scaling upgrading migration disaster recovery monitoring and resource management 例えば、容量足りなくなってきたからストレージ用のworker nodeを増やそうって時に、worker nodeをブスッと追加するだけで、自動的にババババっとストレージをスケールアウトして拡張してくれます。 アップグレードも kubectl apply 一発で、全Podのコンテナイメージをチャチャッと順繰りにアップグレードしてくれます。 なんでこんなことができるのかと言うと、Rookが Operator として動くからです。 まあ厳密にはRookが面倒をみられるSDSごとにOperatorがあって、それによってできることは違うんですが、いずれにせよSDSの運用のプラクティスをOperatorとして実装することで自動的な運用を実現しているのです。はい。 ちなみに、Ceph用とEdgeFS用のRook Operatorはすでに OperatorHub に登録されていまーす。 Rookが対応するSDS Rookも人の子ですので、世の中にあまねく存在するSDSの面倒をみられるわけではありません。Rookが対応できるSDSは、今日の時点で次の6つです。 Name API Group Status Ceph ceph.rook.io/v1 Stable CockroachDB cockroachdb.rook.io/v1alpha1 Alpha Cassandra cassandra.rook.io/v1alpha1 Alpha EdgeFS edgefs.rook.io/v1beta1 Beta Minio minio.rook.io/v1alpha1 Alpha NFS nfs.rook.io/v1alpha1 Alpha 引用元 : https://github.com/rook/rook/blob/master/README.md SDS以外にもDBとかNFSとかも対応するんですね。 というか注意してもらいたいのが、Statusのカラムですよ。 StableなのCephだけ！ だから今後ちゃんと使っていく見込みで取り組むなら断然Ceph！ 迷わず行けよ、行けば分かるさ！ ていうかそもそもCloud-Nativeなストレージだと何が嬉しいの 従来型のストレージとCloud-Native Storageの違い 最初に書いた通り、外部ストレージでもPVを提供できるのであえてCloud-Nativeなストレージにしなくてもいいじゃんっていう意見はあると思います。うん、過去の投資を最大限活用するのは大事だし、一理ある。 しかしCloud-Native Storageにはもちろんメリットがあって、それを認識するポイントは『ストレージをアプリにストレージサービスを提供するインフラアプリとして捉える』というとこかなと思います。 ストレージがk8sのインフラアプリになるということは、 k8s上のアプリケーション専用のストレージが提供できる DataPathがk8s内で閉じる(プロセス間通信)のため速いレスポンスが期待できる k8s外のワークロードを心配しなくてよい ストレージの運用をk8sから行える k8sと全く異なる体系のストレージ管理手順を覚えなくていい Operatorがあれば運用自動化ができる SDSのPodが落ちてもすぐ復活する RobustだけでなくResilientなストレージシステム k8sが稼働するプラットフォームならどこでも同じように動く オンプレ / パブリッククラウド問わず、同じユーザーエクスペリエンス(使用感)を提供できる SDSのコピーサービスを使うことでクラウド間のデータコピーやマイグレーションがしやすい 一般的にこんなメリットが考えられます。 まあユーザーさんごとに事情が違うから、納得してくれる人も居れば嘘くせーと思う人も居ると思います。僕だって別の立場だったら正直ちょっと胡散臭いと感じるかも。 っていうかこんな能書きだけで良さを感じてもらうのはやっぱね、なかなか難しいでしょう。ここはエンジニアブログなんだから。てめぇの力で勝ち取ってみろコノヤローってね。 というわけで次回第2話からは実際にRookを入れてみて使いながらRookのいいとこを紹介していきまーす。 今回はここまで。

Red Hat の小林俊哉です。Drools/jBPM には Kogito という新規プロジェクトがあり、Drools/jBPM を軽量に適用するアプローチを目指しています。そしてその中心となるのが Quarkus との組み合わせです。この記事を参照して動かしてみてください。 tokobayashi.hatenablog.com

Red Hatの福岡オフィスでソリューションアーキテクトをしている田中司恩です。OpenShift 4.1をUPIでベアメタル環境にインストールする方法について解説します。基本的にはインストールドキュメントの要約になりますが、初めてOpenShiftに触れる方にも分かりやすいように順を追って説明していきます。 *1 なお、AWSへのUPIインストールについては、前の記事で林さんが書かれていますのでそちらを参考にしてください。 rheb.hatenablog.com 2019/10/30追記。 OpenShift 4.2がGAになりましたので、4.1からの変更点について下記の記事にまとめました。 rheb.hatenablog.com 本記事の章立てはこのようになります。 UPIインストールの概要 UPIインストールの事前準備 UPIインストールの実施手順 参考：踏み台サーバーの構築 ゴールは「手作業でベアメタル環境にOpenShift 4.1をインストールし手順について理解する」です。 UPIインストールの概要 まず、OpenShift 4.1のUPIインストールの概要から説明していきます。 ドキュメント インストール方法について記載されたドキュメントは日本語、英語どちらもあります。本記事では下記の日本語ドキュメントを対象とします。 *2 第3章 ベアメタルへのインストール OpenShift Container Platform 4.1 | Red Hat Customer Portal IPI/UPIについて OpenShift 4のインストール方法はIPIとUPIの2種類があります。IPIは「 Installer Provisioned Infrastructure 」の略で、自動でインフラ環境を作成してインストールを行う方法です。 それに対しUPIは「 User Provisioned Infrastructure 」の略で、ユーザーがインフラ環境を事前に用意してインストールを行う方法です。ユーザーが環境を準備する手間はありますが、自由に用意した環境にインストールを行うことができます。現時点でUPIで対応しているインストール環境は下記の通りです。 *3 *4 AWS VMware vSphere ベアメタル Infrastructure Provider UPIインストール構成 UPIではユーザーが自由に環境を用意できる反面、必要な要件を満たすインフラの知識が無いと、どのようにインフラ環境を構成すればよいか悩むことと思います。 そこで、本記事では下記の検証環境をサンプルとして説明を進めていきます。 *5 検証環境ネットワーク構成図 UPIインストールの事前準備 次に、構成に必要なものについて説明していきます。UPIインストールにおいて、ここが一番時間のかかるポイントになります。 この事前準備がきっちりと出来ていれば、インストール作業自体はそれほど時間はかかりません。 *6 ノードの準備 UPIインストールで必要なノードの情報は下記の通りです。 マシン 台数 OS vCPU RAM ストレージ 備考 Bootstrap Node 1 RHCOS 4 16GB 120GB UPIインストール時のみ必要 Master Node 3 RHCOS 4 16GB 120GB 3台必須 Worker Node 2 RHCOS 2 8GB 120GB 2台以上 インストールする検証目的だけであれば、Bootstrap NodeのRAM容量はもう少し下げても大丈夫です OSは全て「RHEL CoreOS（RHCOS）」を使用します *7 インストーラー、イメージの入手 この記事の検証環境ではRHCOSはISO起動、BIOSマシンを使用します。 実際に必要なファイルの例は下記のようになります。 名前 インストールor配置先 実際のファイル名(参考: v4.1.3) 備考 oc client 踏み台サーバー *8 openshift-client-linux-4.1.3.tar.gz linux,mac,windows版有り openshift-install 踏み台サーバー *9 openshift-install-linux-4.1.3.tar.gz linux,mac版有り RHCOS ISOイメージ Bootstrap,Master,Worker Node rhcos-4.1.0-x86_64-installer.iso OpenShiftのリリースバージョンと 必ずしも一致するものではありません。 *10 BIOSファイル 踏み台サーバー（Web公開ディレクトリ） rhcos-4.1.0-x86_64-metal-bios.raw.gz BIOS,UEFI版有り バージョンについてはRHCOSと同様 oc client,openshift-installは、展開してREADMEを参考にバイナリファイルを配置してください RHCOS ISOイメージは、用意したベアメタルのノードに合わせて、メディアやISO起動ができるようにしてください BIOSファイルは、この後のWeb Serverの項目を参考にしてファイルを配置してください ※※※ 製品のダウンロードについては、試用や評価に関する解説記事ができましたのでこちらを参照ください。※※※ rheb.hatenablog.com ネットワーク要件 UPIインストールに必要なネットワークの要件について説明します。 対応するドキュメントは、 3.1.4. ユーザーによってプロビジョニングされるインフラストラクチャーの作成 です。 1. 基本要件 検証環境における 検証用ネットワーク 内では、各ノードの全ての通信が通る構成となります。 *11 また、 検証用ネットワーク からインターネットへは自由に通信ができる構成です。 *12 2. ネットワーク設計 検証用ネットワーク を設ける場合は、OpenShiftの内部で使用するネットワークアドレスと被らないようにする必要があります。 ドキュメントでは下記のアドレスが例として載っています。 10.128.0.0/14 ： クラスターネットワーク （Pod IP の割り当てに使用される IP アドレスのブロック） 172.30.0.0/16： サービスネットワーク （サービス IP アドレスに使用する IP アドレスプール） 検証環境でも上記をそのまま使用します。検証環境のネットワーク設計は下記のようになります。 192.168.1.0/24： 社内ネットワーク 172.16.0.0/24： 検証用ネットワーク 3. DHCP RHCOSマシンは初回起動時にDHCPによるIPアドレスの割り当てが必要です。 検証環境では、MACアドレスを指定して固定でホスト名、IPアドレスを割り当てる方法を行います。 検証環境のDHCPの設定例は下記のようになります。 マシン ホスト名 IPアドレス サブネットマスク ゲートウェイ DNSサーバー Bootstrap Node bootstrap.test.example.local 172.16.0.100 255.255.255.0 172.16.0.1 172.16.0.1 Master Node master-0.test.example.local master-1.test.example.local master-2.test.example.local 172.16.0.101 172.16.0.102 172.16.0.103 255.255.255.0 172.16.0.1 172.16.0.1 Worker Node worker-0.test.example.local worker-1.test.example.local 172.16.0.104 172.16.0.105 255.255.255.0 172.16.0.1 172.16.0.1 4. DNS 下記の指定されたレコードの名前解決が必須です。 コンポーネント レコード 対象ノード Kubernetes API api.<cluster_name>.<base_domain> api-int.<cluster_name>.<base_domain> Bootstrap,Master Routes *.apps.<cluster_name>.<base_domain> Worker etcd etcd-<index>.<cluster_name>.<base_domain> _etcd-server-ssl._tcp.<cluster_name>.<base_domain> Master 検証環境で登録したDNSの設定例は下記のようになります。 ホスト名 IPアドレス 備考 api.test.example.local 192.168.1.21 LBの外側アドレスを指定 api-int.test.example.local 172.16.0.1 LBの内側アドレスを指定 *.apps.test.example.local 172.16.0.1 LBの内側アドレスを指定。ワイルドカードDNSレコード。 etcd-0.test.example.local 172.16.0.101 システム内部でetcd-0,1,2で固定名で名前解決を行うので、 Master Nodeのホスト名とは別で登録必要 etcd-1.test.example.local 172.16.0.102 同上 etcd-2.test.example.local 172.16.0.103 同上 レコード 優先度 重み ポート DNS名 _etcd-server-ssl._tcp.test.example.local 0 10 2380 etcd-0.test.example.local _etcd-server-ssl._tcp.test.example.local 0 10 2380 etcd-1.test.example.local _etcd-server-ssl._tcp.test.example.local 0 10 2380 etcd-2.test.example.local 5. Load Balancer 下記のポート番号のロードバランサーが必要です 用途 ポート番号 対象ノード Kubernetes APIServer 6443 Bootstrap,Master マシン設定サーバー 22623 Bootstrap,Master ingressルーターのhttpアクセス用 80 Worker ingressルーターのhttpsアクセス用 443 Worker 検証環境で登録したLoad Balancerの設定は下記のようになります ポート番号 SSL バックエンド 6443 Yes bootstrap.test.example.local master-0.test.example.local master-1.test.example.local master-2.test.example.local 22623 Yes bootstrap.test.example.local master-0.test.example.local master-1.test.example.local master-2.test.example.local 80 - worker-0.test.example.local worker-1.test.example.local 443 Yes worker-0.test.example.local worker-1.test.example.local ブートストラッププロセス終了後はBootstrap Nodeの設定は不要ですので、Load Balancerの登録から削除できます 6. Web Server ドキュメントには詳細な記載はありませんが、インストール作業に必要なファイルをHTTPサーバーに配置する必要があります。 検証環境では、 nginx でWeb Serverを稼動し、Web公開ディレクトリに必要なファイルの配置を行います。 なお、 nginx のポート番号はLoad Balancerの設定と被らないように、検証環境ではTCP 80 → 8008 へ変更しています。 *13 検証環境で使用するWeb公開ディレクトリのサンプルは下記のようになります。 /usr/share/nginx/html/ ├── ocp    └── rhcos    ├── ignitions    │   ├── bootstrap.ign    │   ├── master.ign    │   └── worker.ign    └── images    ├── latest    │   ├── bios.raw.gz -> ../release/410/rhcos-4.1.0-x86_64-metal-bios.raw.gz    └── release    └── 410    └── rhcos-4.1.0-x86_64-metal-bios.raw.gz ignitions以下の*.ign ファイルは、この後のインストール作業で作成したものを配置します CoreOS Imageの元のファイル名は長いので、リンクで短縮名にしています。リネームして配置しても問題ありません。 *14 踏み台サーバー 検証環境では、RHEL8のサーバーを1台用意してネットワーク要件で必要なサービスを全てここで稼動しています。 踏み台サーバーとして備えるべき、必要な要件は下記の通りです。 2つのネットワークカード（ 社内ネットワーク 、 検証用ネットワーク に接続） 社内ネットワークからインターネットへアクセスが可能な固定IPを一つ ネットワーク要件で上げたサービスが稼動できるリソースを持つマシン 詳細な設定内容については、記事の最後の「参考：踏み台サーバーの構築」を参考にしてください。 操作端末 社内ネットワーク から踏み台サーバーを経由して、 検証用ネットワーク にアクセスするために使用します。 社内ネットワーク のルーターなどに 検証用ネットワーク へのルーティングの追加が難しい場合は、操作端末に静的ルートを追加して対応してください。 SSH Client：踏み台サーバーにログインしてopenshift-installコマンドの実行、他。踏み台サーバーから各ノードにSSH接続してデバッグ操作、ログ確認など。 *15 Webブラウザ ：新規クラスタ作成後、Web Consoleへの接続用。 SSHキーペアの準備 この作業では、各ノードに対してSSH公開鍵認証でアクセスするために必要なSSHキーペアの作成を行います。 対応するドキュメントは、 3.1.5. SSH プライベートキーの生成およびエージェントへの追加 です。 指定したSSH公開鍵が、各ノード（Bootstrap,Master,Worker）の core ユーザーの ~/.ssh/authorized_keys に追加されます。 *16 ドキュメントでは下記のコマンドが例として載っています。 $ ssh-keygen -t rsa -b 4096 -N '' -f ~/.ssh/new_rsa ドキュメントではキーの生成後にssh-agentの起動の手順がありますが、UPIインストールをする目的においては必須ではありませんので、飛ばしても大丈夫です。 *17 UPIインストールの実施手順 ここから、実際のインストール作業について説明していきます。 インストールのステップ インストールの進行は下記の順で行います。また、各項目はドキュメントの 3.1.8〜3.1.15 に対応します。 各項目の作業内容は基本的にドキュメント通りとなりますので、詳細はドキュメントの該当箇所を参照ください。 1. 準備 項目 対応ドキュメント章 1.a インストール設定ファイルの手動作成 3.1.8 1.b Ignition 設定ファイルの作成 3.1.9 1.c Red Hat Enterprise Linux CoreOS (RHCOS) マシンの作成 3.1.10 ※ 1.bで作成したIgnition 設定ファイルには、24 時間後に期限が切れる証明書が含まれます。万が一24時間を超えてインストールを実行する場合は、再度1.bから行ってください。 2. インストール作業 項目 Bootstrap Node 対応ドキュメント章 2.a クラスターの作成 必要 3.1.11 2.b クラスターへのログイン 不要 3.1.12 2.c マシンの CSR の承認 不要 3.1.13 2.d Operator の初期設定 不要 3.1.14 2.e UPIのインストールの完了 不要 3.1.15 1.a インストール設定ファイルの手動作成 この作業は踏み台サーバーで行います。 ここでの作業の目標は、インストールディレクトリの作成と、インストール設定ファイル install-config.yaml を作成することです。注意点は、ドキュメントにも記述がある通り、 install-config.yaml をインストールディレクトリ以外に保存しておくことです。 インストールディレクトリ： bare-metal $ mkdir bare-metal $ vi install-config.yaml $ cp install-config.yaml bare-metal/ 検証環境の install-config.yaml は下記のような内容になります。 *18 ドメイン名: example.local クラスタ名： test 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...' pullSecret: には、下記のページから Copy Pull Secret を押してコピーした内容を貼り付けます。 https://cloud.redhat.com/openshift/install/metal/user-provisioned sshKey: には、事前準備で用意したSSH公開鍵の内容（ ~/.ssh/new_rsa.pub ）を貼り付けます。 1.b Ignition 設定ファイルの作成 引き続きこの作業も踏み台サーバーで行います。 ここで行うことは、1.aで作成した内容を元に、インストールに必要なIgnition 設定ファイルなどを作成します。 行うことは下記のコマンドを1行実行するだけです。 $ openshift-install create ignition-configs --dir=bare-metal このコマンドの実行後に、インストールディレクトリ内の install-config.yaml は削除されます。 実行後のインストールディレクトリは下記のようになります。 bare-metal ├── auth │ ├── kubeadmin-password │ └── kubeconfig ├── bootstrap.ign ├── master.ign ├── metadata.json └── worker.ign ドキュメントには記載がありませんが、実際の手順では作成した各ignitionファイルをWeb Serverの公開ディレクトリにコピーします。 検証環境では下記のようになります。 cp bare-metal/*ign /usr/share/nginx/html/ocp/rhcos/ignitions/ 1.c Red Hat Enterprise Linux CoreOS (RHCOS) マシンの作成 この作業は各ノードのコンソール画面で行います。 ここでは、各ノードのベースOSのRHCOSを用意して、起動→初期パラメーターの入力を行うところまでを行います。 用意した各ノードをISOイメージで起動します。 ドキュメントでは起動順に特に指定はありませんが、ブートストラッププロセスにおいて、Master,Worker NodeがBootsrap Nodeからコンフィグファイルを取得するプロセスがあります。 起動順を設ける場合は、Bootstrap Nodeを先に起動するのが望ましいです。 *19 この後の手順は全ノード共通です（ignition config URLの指定先を除く）。 ISO起動後、RHEL CoreOS InstallerのGUI画面が表示されます。 Install RHEL CoreOS が選択されていますので、そのままエンターキーを押します。 RHEL CoreOS Installer GUI画面 次に、CoreOS Image URLの入力を求められますので、デフォルトの入力内容を消して指定のURLパスを入力し、エンターキーを押します。 CoreOS Image URLの入力 このタイミングでファイルにアクセスできるかチェックが行われます。エラーになる場合は、URLパスやポート番号に間違いが無いか確認してください さらに、CoreOS ignition config URLの入力を求められます。先程と同様に、デフォルトの入力内容を消して指定のURLパスを入力し、エンターキーを押します。 ここではBootstrap Nodeのignition設定ファイルを指定 CoreOS ignition config URLの入力 ここも、先程と同様にファイルにアクセスできるかチェックが行われます。 指定する *.ignファイルは、各ノードの種類に合わせて変更します 最後に、インストール先デバイスの指定を求められます。 sda を選択し、 OK を押します。 インストール先デバイスの指定 CoreOS Image のダウンロード始まり、問題なく取得が完了すると自動で再起動が行われ、RHEL CoreOSが起動します。 この作業を全ノードについて行います。 2.a クラスターの作成 ここからWeb Consoleへのログインまでは、踏み台サーバーでの作業となります。 前項1.cの終了時点から、ブートストラッププロセスは自動的に進行しています。 ここでは、下記のコマンドを実行し、ブートストラッププロセスの進行と完了をモニタリングします。 $ openshift-install --dir=bare-metal wait-for bootstrap-complete 下記のような表示になるとブートストラッププロセスが完了したことが分かります。 openshift-install --dir=bare-metal wait-for bootstrap-complete INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.local:6443... INFO API v1.13.4+d4417a7 up INFO Waiting up to 30m0s for bootstrapping to complete... INFO It is now safe to remove the bootstrap resources 30分以上掛かっても完了しない場合は、事前準備が不足か間違っている可能性が高いです。 途中で止めてやり直す場合は、1.cのISO起動からやり直します 2.b クラスターへのログイン ここでは、 kubeadmin 認証情報をエクスポートし、デフォルトシステムユーザーでログインできることを確認します。 $ export KUBECONFIG=bare-metal/auth/kubeconfig $ oc whoami system:admin oc whoami の結果、 system:admin が返ってくれば完了です。 ブートストラッププロセスの完了直後すぐだと、エラーが返ってくることがあります。その場合は、少し時間を置いて再度実行します。 2.c マシンの CSR の承認 ここでは、各ノードがクラスタに追加された際に作成される証明書署名要求が、全て承認されているか確認します。 まず、クラスターにノードが追加されているか確認します $ oc get nodes NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.13.4+b626c2fe1 master-1 Ready master 63m v1.13.4+b626c2fe1 master-2 Ready master 64m v1.13.4+b626c2fe1 worker-0 NotReady worker 76s v1.13.4+b626c2fe1 worker-1 NotReady worker 70s v1.13.4+b626c2fe1 証明書署名要求の承認状態を確認します。 $ oc get csr 全ての項目が、証明状態になっていることを確認します もし、なっていなければ、ドキュメントの手順で手動で承認を行なってください。 *20 2.d Operator の初期設定 ここでは、全てのOperatorが正常に稼動していること確認します。 $ watch -n5 oc get clusteroperators 上記のコマンドで、5秒ごとに実行される oc get clusteroperators の結果をモニタリングします。 Operatorが次々と立ち上がっていく様子が確認できます。 最終的に全てのOperatorのステータスにおいて AVAILABLE が TRUE 、 DEGRADED が FALSE になることがゴールです。 *21 ※ストレージのイメージレジストリーへの提供（対象ドキュメント：3.1.14.1） image-registry operatorについては、自動的に AVAILABLE が TRUE にはなりません。 下記のコマンドを実行して、空のディレクトリを指定します。 $ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}' ドキュメントにも記載はありますが、このオプションは 実稼働用以外のクラスターにのみ 設定します。 この記事ではインストールの完了を目標としますので、このオプションを実行します。 本番運用時は適切な設定に変更してください。 詳細な設定方法は下記を参照。 2.4.2. ベアメタルの場合のレジストリーストレージの設定 Operatorが正常に起動した状態は下記のようになります。 # oc get clusteroperators NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE authentication 4.1.3 True False False 46s cloud-credential 4.1.3 True False False 12m cluster-autoscaler 4.1.3 True False False 12m console 4.1.3 True False False 4m17s dns 4.1.3 True False False 11m image-registry 4.1.3 True False False 7m17s ingress 4.1.3 True False False 7m34s kube-apiserver 4.1.3 True False False 11m kube-controller-manager 4.1.3 True False False 9m31s kube-scheduler 4.1.3 True False False 9m40s machine-api 4.1.3 True False False 12m machine-config 4.1.3 True False False 10m marketplace 4.1.3 True False False 7m26s monitoring 4.1.3 True False False 5m32s network 4.1.3 True False False 12m node-tuning 4.1.3 True False False 8m57s openshift-apiserver 4.1.3 True False False 8m54s openshift-controller-manager 4.1.3 True False False 11m openshift-samples 4.1.3 True False False 2m33s operator-lifecycle-manager 4.1.3 True False False 10m operator-lifecycle-manager-catalog 4.1.3 True False False 11m service-ca 4.1.3 True False False 11m service-catalog-apiserver 4.1.3 True False False 9m4s service-catalog-controller-manager 4.1.3 True False False 9m5s storage 4.1.3 True False False 8m6s 2.e UPIのインストールの完了 インストール作業の最終段階です。 前項2.dで全てのOperatorが正常に動作していることを確認後、下記のコマンドを実行します。 $ openshift-install --dir=bare-metal wait-for install-complete その後、インストールプロセスが正常に完了すると、Web Consoleへのログイン情報が表示されます。 これでUPIのインストール作業は完了です。 INFO Waiting up to 30m0s for the cluster at https://api.test.example.local:6443 to initialize... INFO Waiting up to 10m0s for the openshift-console route to be created... INFO Install complete! INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/root/OCP/bare-metal/auth/kubeconfig' INFO Access the OpenShift web-console here: https://console-openshift-console.apps.test.example.local INFO Login to the console with user: kubeadmin, password: XXXXX-XXXXX-XXXXX-XXXXX 最後に表示された user: kubeadmin,password: XXXXX-XXXXX-XXXXX-XXXXX を使用して、Web Consoleへログインします。 Web Consoleへのログイン 最後に、WebブラウザでWeb Consoleにアクセスして、クラスタが正常に稼動しているか確認します。 検証環境では、下記のアドレスにアクセスします。 https://console-openshift-console.apps.test.example.local Web Consoleへのログイン ログイン後、 Administration > Cluster Status でクラスターのステータスに問題が無ければ正常稼動しています。 Cluster Status まとめ 以上、OpenShift 4.1をベアメタル環境にインストールする手順の紹介でした。 ここから先はOpenShiftに実際に触れる世界になります。 是非、身近な環境にOpenShiftをインストールしてどんどん使ってみて下さい！ Let's get Big Ideas ! 参考：踏み台サーバーの構築 本記事の検証環境で使用した踏み台サーバーを構築するための設定のサンプルを載せておきます。 RHELの設定 1. サブスクリプション登録 # subscription-manager register # subscription-manager attach --pool <ID> 2. IPv6無効化、IPv4ルーティング # vi /etc/sysctl.d/99-custom.conf net.ipv6.conf.all.disable_ipv6 = 1 net.ipv4.ip_forward = 1 # sysctl -p /etc/sysctl.d/99-custom.conf 3. SELinux # setsebool -P httpd_read_user_content 1 # setsebool -P haproxy_connect_any 1 4. 不要なサービスの停止 avahi-daemon systemctl disable avahi-daemon.service systemctl stop avahi-daemon* cups # systemctl stop cups.service # systemctl disable cups.service rpcbind # systemctl stop rpcbind.service # systemctl stop rpcbind.socket # systemctl disable rpcbind.service # systemctl disable rpcbind.socket libvirtd # systemctl stop libvirtd.service # systemctl disable libvirtd.service 5. NIC設定 社内ネットワーク側（ens192） # nmcli con modify ens192 ipv4.method manual # nmcli con modify ens192 ipv4.addresses 192.168.1.21/24 # nmcli con modify ens192 ipv4.gateway 192.168.1.1 # nmcli con modify ens192 ipv4.dns 127.0.0.1 # nmcli con modify ens192 ipv6.method ignore 検証用ネットワーク側（ens224） # nmcli con modify ens224 ipv4.method manual # nmcli con modify ens224 ipv4.addresses 172.16.0.1/24 # nmcli con modify ens224 ipv6.method ignore firewalld # firewall-cmd --set-default-zone=trusted # firewall-cmd --add-masquerade --zone=trusted --permanent # firewall-cmd --reload dnsmasq # vi /etc/dnsmasq.conf サンプルコンフィグ（コメント行を除く） port=53 domain-needed bogus-priv resolv-file=/etc/resolv.dnsmasq no-poll address=/apps.test.example.local/172.16.0.1 user=dnsmasq group=dnsmasq no-dhcp-interface=ens192 expand-hosts domain=test.example.local dhcp-range=172.16.0.100,172.16.0.200,255.255.255.0,12h dhcp-host=XX:XX:XX:XX:XX:XX,bootstrap,172.16.0.100 dhcp-host=XX:XX:XX:XX:XX:XX,master-0,172.16.0.101 dhcp-host=XX:XX:XX:XX:XX:XX,master-1,172.16.0.102 dhcp-host=XX:XX:XX:XX:XX:XX,master-2,172.16.0.103 dhcp-host=XX:XX:XX:XX:XX:XX,worker-0,172.16.0.104 dhcp-host=XX:XX:XX:XX:XX:XX,worker-1,172.16.0.105 dhcp-option=option:dns-server,172.16.0.1 dhcp-leasefile=/var/lib/dnsmasq/dnsmasq.leases srv-host=_etcd-server-ssl._tcp.test.example.local,etcd-0.test.example.local,2380,0,10 srv-host=_etcd-server-ssl._tcp.test.example.local,etcd-1.test.example.local,2380,0,10 srv-host=_etcd-server-ssl._tcp.test.example.local,etcd-2.test.example.local,2380,0,10 log-dhcp log-facility=/var/log/dnsmasq.log conf-dir=/etc/dnsmasq.d,.rpmnew,.rpmsave,.rpmorig resolv.conf # vi /etc/resolv.conf nameserver 127.0.0.1 resolv.dnsmasq # vi /etc/resolv.dnsmasq nameserver 192.168.1.1 hosts # vi /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 #for OCP4 192.168.1.21 api 172.16.0.1 api-int 172.16.0.101 etcd-0 172.16.0.102 etcd-1 172.16.0.103 etcd-2 サービス登録、起動 # systemctl enable dnsmasq.service # systemctl start dnsmasq.service HAproxy # yum install haproxy # vi /etc/haproxy/haproxy.cfg サンプルコンフィグ（global,defaultsは初期コンフィグから変更無し。frontend,backendのみ記載） frontend K8s-api bind *:6443 option tcplog mode tcp default_backend api-6443 frontend Machine-config bind *:22623 option tcplog mode tcp default_backend config-22623 frontend Ingress-http bind *:80 option tcplog mode tcp default_backend http-80 frontend Ingress-https bind *:443 option tcplog mode tcp default_backend https-443 backend api-6443 mode tcp balance roundrobin option ssl-hello-chk server bootstrap bootstrap.test.example.local:6443 check server master-0 master-0.test.example.local:6443 check server master-1 master-1.test.example.local:6443 check server master-2 master-2.test.example.local:6443 check backend config-22623 mode tcp balance roundrobin server bootstrap bootstrap.test.example.local:22623 check server master-0 master-0.test.example.local:22623 check server master-1 master-1.test.example.local:22623 check server master-2 master-2.test.example.local:22623 check backend http-80 mode tcp balance roundrobin server worker-0 worker-0.test.example.local:80 check server worker-1 worker-1.test.example.local:80 check backend https-443 mode tcp balance roundrobin option ssl-hello-chk server worker-0 worker-0.test.example.local:443 check server worker-1 worker-1.test.example.local:443 check サービス登録、起動 # systemctl enable haproxy.service # systemctl start haproxy.service nginx # yum install nginx # vi /etc/nginx/nginx.conf サンプルコンフィグ（初期コンフィグから変更点のみ記載） http { server { listen 8008 default_server; # ポート番号変更：80->8008 # listen [::]:80 default_server; # コメントアウト } disable_symlinks off; # 追加 } サービス登録、起動 # systemctl enable nginx # systemctl start nginx *1 : UPIでベアメタル環境へのインストールができるようになると、OpenShift 4の基本のアーキテクチャについて理解が深まり、他の環境へのインストールにも応用ができるようになると思います *2 : openshift.comにも英語のみですが同様のドキュメントがあります。Red Hat OpenShift Cluster Managerからリンクしているドキュメントはこちらになります。本記事の内容と合わせて読み進め下さい。 Installing a cluster on bare metal - Installing on bare metal | Installing | OpenShift Container Platform 4.1 *3 : Microsoft Azure上へのインストールは現在Developer Previewです *4 : テスト済みの環境情報についてはこちら（カスタマーポータルへのログインが必要） https://access.redhat.com/articles/4128421 *5 : この記事の最大のポイントはココで、「必要最低限の構成、変更でいかにOpenShift 4を構築するか」、に重点をおいています *6 : 環境にも寄りますが、手元の検証環境では20-30分程度でクラスタの作成が完了します *7 : Worker NodeにRHEL7.6を使用するオプションもあります *8 : UPIインストール後は操作端末に導入してあれこれ操作するのもありです *9 : 操作端末がMacかLinuxであればそこでの利用は可能ですが、この検証環境では踏み台サーバー上で作業を完結することを想定して構成しています *10 : ドキュメントより：「RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。」 *11 : 全てのマシン間で必要な通信ポートはドキュメントに記載があります→表3.1 *12 : quay.ioからのイメージプルと、cloud.redhat.comへのTelemetryデータの通信が必要です *13 : SELinuxでhttp_port_t に登録されている番号を使用 *14 : リリースが増えてた場合を見越して指定しやすいようにしています *15 : RHCOSの各ノードへは公開鍵認証方式でのSSH接続が必要です。SSH Agentに対応しているものがベターです *16 : ドキュメントでは「このキーを使用して、ユーザー core としてマスターノードに対して SSH を実行できます。」とありますが、実際にはBootstrap,Master,WorkerいづれのノードにもSSHでアクセスできます。 *17 : ログの確認などの手順はまた別記事でまとめられればと思います *18 : baseDomain（ドメイン名）とname（クラスタ名）以外はドキュメントのサンプル通り。pullSecretとsshKeyの内容はシングルクォーテーションで囲まれるように。 *19 : 全台同時起動でも問題無いです。コンフィグファイルの取得ができるまで、Master,Worker Nodeは待機します。 *20 : あくまで経験上ですが、繰り返し新規クラスタを作成している中ではここは必ず全て承認状態になっていました。 *21 : ドキュメントには「全てのOperatorがAVAILABLEの場合インストールを完了することができます」と記載があります。実際、一部にDEGRADEDがある状態でもコマンド上はインストール完了になります。しかしながら、Web Console上ではエラーが発生していたり、OpenShiftとしての構築が未完了の状態になることがあります。

Red HatでOpenShiftのサポートエンジニアをしている林です。 OpenShift 4は、openshift-installコマンドをちょいちょいと叩くとVMやLB、DNSの設定等々すべて実施してくれて、苦労せずクラスタを構築できる便利なプラットフォームです。 特に理由がなければこの方法でクラスタを構築することをお勧めしたいところです。 しかし、 openshift-installコマンドが構築する環境が要件に合わない そもそもopenshift-installコマンドが対応していないIaaSを使用している などの理由で、どうしてもopenshift-installにインフラの構築を任せることができないという場合があります。 そのため、OpenShift 4は、自分でインフラを構築して、そこにOpenShift 4をインストールするという方法で構築することもできるようになっています。 このように、自分でインフラを作ってOpenShift 4をインストールする手順をUPI、User-provisioned infrastructureといった言葉でドキュメントでは呼ばれています。 docs.openshift.com User-provisionedというくらいなので、ユーザーの環境、要件によりその手順は様々です。上記のOpenShiftドキュメントでは、Cloud Formationを使用してインフラを構築する例が紹介されています。 私は、Terraformが好みなので、Terraformを使用して以下のような構成でAWS上にインフラを作成し、OpenShift 4をインストールしてみました。 UPI Overview 手順やスクリプトの詳細については、以下のGitHubプロジェクトにアップロードしましたので見てみてください。 github.com 比較的小規模かつ、拡張可能な形になっているかと思いますので、手順やスクリプトをいじってみるのも面白いと思います。 実際には、インストーラー(openshift-installコマンド)でクラスタを構築するとしても、一度上記のようなHard Wayで構築してみることで、OpenShiftやKubernetesに対する理解が深まるかもしれません。

Red Hat の小林俊哉です。オープンソースのルールエンジン Drools のブログです。ステートレス ksession、KJAR についての記事を追加しました。短くて簡単に読めます！ tokobayashi.hatenablog.com tokobayashi.hatenablog.com

Red Hat の古市です。Red Hat Fuse の内部でも使われている Apache Camel の次期メジャーバージョンとなる Camel 3 について、昨日(2019/6/25) Claus Ibsen氏がブログを執筆されました。 和訳版をご用意したので、ぜひこちらもご活用ください。 和訳: playintegration.blogspot.com 原文: Claus Ibsen (@davsclaus) riding the Apache Camel: Apache Camel 3 - camel-core vs camel-core-engine (smaller core) 補足となりますが、Apache Camel のツイッターアカウントがあります。こちらをフォローしていただく事で、Apache Camel の最新情報をご確認いただけます。ぜひ！ Apache Camel (@ApacheCamel) | Twitter

こんにちは、レッドハットでマーケティングを担当している中村です。今回は、1ヶ月くらい経ってしまいましたが、2019年5月28日に実施したRed Hat Tech Nightのレポートを簡単にしたいと思います。 Red Hat Tech Nightとは Red Hat Tech Nightは2018年のRed Hat Forumと同時に、ひとりのエンジニアの呼びかけから、わずか5営業日で発足したイベントです。レッドハット社内には、OSSの情報を発信したり、コミュニティ活動を運営している人が何名かおり、そのような社員が有志でOSS Advocateとして活動しています。OSS Advocateの活動の一環として、この赤帽エンジニアブログも運営していたりします。 Red Hat Tech Nightとは、レッドハットが関係しているOSSに関する情報を共有し、学んでいただくTechなNightです。レッドハットでOpen OrganizationとOSSのを推進したいという思いのある有志メンバーが企画し、運営を開始しました。 rheb.hatenablog.com Red Hat Tech Night 2019.05 の様子 キャパ以上に参加申込みを頂いたRed Hat Tech Night 2019.05。 ビールたくさん 今回も、レッドハットのエンジニアが喋りたい内容を好きなようにしゃべるという形式で実施いたしました。第1回はパネルディスカッションのようなことを実施しましたが、今回はLTのみという大胆な企画。合計12名のレッドハッターに登壇してもらいました。 内容は多岐に渡り、レッドハットが持つポートフォリオほぼ全てをカバーするような内容、かつ オープンソースコミュニティ（アップストリーム開発）での動きなどの情報もありました。ディープすぎた感じも否めませんが、これがレッドハットなのか！と感じていただけたらと思います。 当日のアジェンダ： 1: はじめてのPull Request - AWX編 by @saito_hideki 2: 5分で理解するQuarkus by @nobusue 3: Camel 3 by @tadayosi 4: multus-cniの話 by @s1061123 5: virtual-kubeletでOSSとマネージドサービスのいいとこ取りを考える by @mosuke5 6: マイラボをもっとゴージャスに！（仮） by toaraki 7: OpenShift の S2I (Source-to-Image) の内部動作について調査してみた件 by mamomamo 8: Ansible 2.8 x Windows(仮) by @hiyoko_taisa 9: OpenStack Octavia入門 by tkajinam 10: OpenShift-SDNの話 by @orimanabu 11: オレにFedora 30の話をさせてくれ by @htaira 12:レッドハット人事が語る！「こんなレッドハットが大好き！」by @teihijapan エンジニアセッションはCall For Presentaionという形で社内で募集をし、手を上げてくれたメンバーで、レッドハット歴がまだ浅い人も含めていろんな人が手を上げてくれました。また、最後のLTはエンジニアではなく、レッドハットで人事を担当している人に講演をしてもらったのですが、これが結構ウケたのでまたこういった変わり種も入れ込んでいければと思っています。 当日の資料は、Connpassにもアップロードされていますので、そちらからご参照ください。 ossbyredhat.connpass.com また、当日のTwitter実況中継はtogetterにもまとまっていますので、当日の雰囲気を知りたい方はこちらをご参照ください。 togetter.com さいごに レッドハットでは、レッドハットが関係するOSSコミュニティへのサポートを積極的に実施しています。まだこのコミュニティへのサポートがないよ！などということがあれば是非お気軽にお声がけください。 また、今年開催を企画中であるRed Hat ForumでもRed Hat Tech Nightの実施を計画中です！Tech Nightの実施については、Connpassにてご連絡いたします（こちらのブログでも）。 ossbyredhat.connpass.com 最後に、レッドハットは、エンジニアを大募集中です！奮ってご応募ください！ ▶ テクニカルサポート職 ▶ テクニカルコンサルタント職

Red Hatのさいとうです。 前回の Ansible2.8の新機能1 - Interpreter Discovery から、だいぶ時間がたってしまいましたが、Ansible 2.8で実装された新機能2をお届けします。単に忙しかっただけで書くのを忘れてたわけじゃないんですよ。 今回ご紹介するのは Become Plugin です。 Become機能のプラグイン化 Ansible v2.8以前は、sudoやsuなどのコマンドを利用してrootなどの特定のユーザ権限でPlaybookを実行する機能は、コア機能が利用するライブラリ内で定義されており、利用者が独自に改変したり、拡張したりすることができませんでした。 Ansible v2.8以降では、この機能をプラグイン化してコア機能から切り離すことで、利用者が必要に応じて拡張できるようになりました。 この記事では、必要最低限の機能を実装した独自のbecome pluginを作成して、ansible-playbookコマンド実行時に利用する方法を紹介します。 Becomeプラグインの実装 ここでは、以下のように、 sudo su -c <コマンド> を実行する以下のスクリプト(sudosu)をターゲットホストの/usr/bin/sudosuとして配置して、Playbook実行時にbecome methodとして利用します。 #!/bin/sh sudo su "$@" # # [EOF] # これをターゲットホストに /usr/bin/sudosu として配置したら、実行権を与えておきます。 # chmod +x /usr/bin/sudosu 続いて、become pluginである sudosu.py を作成します。 DOCUMENTATION に ansible_become_user , ansible_become_exe , ansible_become_password を記述するのを忘れないでください。この記述がないと、becomeパラメータとして必要なパスワードなどの情報をプラグインに引き渡すことができません: # -*- coding: utf-8 -*- from __future__ import (absolute_import, division, print_function) __metaclass__ = type from ansible.module_utils.six.moves import shlex_quote from ansible.plugins.become import BecomeBase DOCUMENTATION = """ become: sudosu description: - Testing for custom become_plugin options: become_user: description: User you 'become' to execute the task default: root vars: - name: ansible_become_user become_exe: description: sudosu executable default: sudosu vars: - name: ansible_become_exe become_pass: description: Password to pass to sudo required: False vars: - name: ansible_become_password """ class BecomeModule(BecomeBase): name = 'sudosu' def build_become_command(self, cmd, shell): self.prompt = '[sudo] password for ' command = self.get_option('become_exe') or self.name success_cmd = self._build_success_command(cmd, shell) return '%s -c %s' % (command, shlex_quote(success_cmd)) # # [EOF] # self.prompt にパスワードインタラクション用のプロンプトを設定します。それ以降の記述は、現状ドキュメントが存在していないため、 su.py や sudo.py などを参考にして BecomeBaseクラス を読み解きつつ実装してみました(もちろんちゃんと動作します)。 このプラグインを、以下のようにPlaybookのbecome_pluginディレクトリに配置します: . ├── become_plugins │   └── sudosu.py ├── inventory └── test.yml このプラグインを利用する test.yml は、以下のように記述しています: --- - hosts: all gather_facts: no tasks: - yum: name: wget state: latest become: yes become_method: sudosu become_user: root 最後に、このPlaybookを実行してみます。 --ask-become-pass で sudo su の実行時に聞かれるパスワードを渡すのをお忘れなく。 -vvv オプションを付与して実行すると、タスクの実行に sudosu が使われているのが確認できます。 $ ansible-playbook -i inventory test.yml --ask-become-pass -vvv ansible-playbook 2.8.1 config file = /etc/ansible/ansible.cfg configured module search path = [u'/home/hsaito/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules'] ansible python module location = /home/hsaito/.pyenv/versions/2.7.16/envs/ansible-2.8.1-py27/lib/python2.7/site-packages/ansible executable location = /home/hsaito/.pyenv/versions/ansible-2.8.1-py27/bin/ansible-playbook python version = 2.7.16 (default, May 7 2019, 14:18:00) [GCC 9.0.1 20190312 (Red Hat 9.0.1-0.10)] Using /etc/ansible/ansible.cfg as config file BECOME password: ******** ... <test00> SSH: EXEC sshpass -d8 ssh -C -o ControlMaster=auto -o ControlPersist=60s -o 'User="hsaito"' -o ConnectTimeout=10 -o ControlPath=/home/hsaito/.ansible/cp/22ce55f06b -tt test00 '/bin/sh -c '"'"'sudosu -c '"'"'"'"'"'"'"'"'/usr/bin/python /home/hsaito/.ansible/tmp/ansible-tmp-1561363694.88-125525749171244/AnsiballZ_yum.py'"'"'"'"'"'"'"'"' && sleep 0'"'"'' ... まとめ become plugin(だけじゃないけど)は開発者向けのドキュメントが存在していません。バンドルされているsudoなどのプラグインを読み解いて、がんばって実装するしかありませんが、sudoやsuなどのようにバンドルされているプラグイン以外の権限昇格コマンドを利用したいような場合は、become pluginとして独自に実装できるようになりました。また、プラグイン化されたことで、アップストリームへの機能拡張のリクエストもしやすくなるというメリットもありますので、今後の拡張に期待したいところです(もう世にある権限昇格系のコマンドは既に実装されている気もしますが)。

Red Hatのもえわきです。RHELの翻訳プロジェクトコーディネーター兼トランスレーターをしています。 このたび、ローカリゼーション（各国の言語への翻訳を担当する部署）のRHELチームは、RHEL8の一般公開日（GA）に、日本語ドキュメントを20冊以上公開しました。これほど多くのドキュメントを、RHELのGAと同時に公開することはこれまでなかったとのことで、社内でちょっとした注目をあびました。今回は、GAと同時に日本語ドキュメントを公開するまでの軌跡をご紹介したいと思います。 カスタマーポータルのRHEL8ドキュメントのページ もくじ 目標は、日本語版の「GA公開」 日本語翻訳版をGAに公開するまでの軌跡 PMとの連携が重要 日本オフィスからの意見を吸い上げる 急な修正への対応 大幅な修正が！ ついに！ 最後に 目標は、日本語版の「GA公開」 RHELはRed Hatのコア製品であり、多くのお客様にご利用頂いております。また、RHEL7のリリースから5年も経っているため、日本の多くのお客様、パートナー様からも注目度の高い製品です。 RHEL8は、英語ドキュメント自体も、これまでのメジャーバージョンと異なり「一から書き直し」が計画されていたため、日本語だけでなく英語も（英語も！）、そもそもGAに間に合うか分からないと噂されていました。このような背景から、今回RHEL8の翻訳プロジェクトを進めるにあたり、まずは、ローカリゼージョンプログラムマネージャー（PM）であるLuděk Janda（ルジェック・ヤンダ）と2人で、目標を「GA公開」に定めました。実際には、RHEL7から引き継いだ部分も多く、当初予想されていたよりは工数を短くできたのですが、これまでと作業環境が異なったため課題も多くありました。 英語ドキュメントの作業フォーマットが変更になったため、既存の翻訳が使えず、余計な工数が発生した 英語ドキュメントが絶えず更新されていくため、GAまでに数バージョンの翻訳が必要になった 翻訳に使用するツールを変更したため、さまざまな問題が発生した GAの直前まで英語が更新された GAがゴールデンウィーク直後！ 日本語翻訳版をGAに公開するまでの軌跡 PMとの連携が重要 このように、いろいろ課題がある中で「GA公開」を実現するために、ルジェックと私が行ったことを少し説明します。弊社ローカリゼーションチームはオーストラリアに拠点がありますが、ルジェックはRHELの英語ドキュメントを制作するチームがいるチェコ、私は日本にいるため、RHEL翻訳チームは、PMとコーディネーターともに、協働する相手と近いところにおり、非常に理想的な体制となっております。 日本オフィスからの意見を吸い上げる 私は去年の夏の終わりぐらいにRHELのコーディネーターを担当することになり、同時にRHEL7までの翻訳状況とそれに対する要望を日本オフィスから集め、そのときの意見を踏まえ、「GA公開」の可能性を探し始めました。同時期、ルジェックが英語ドキュメントチームと話し合いを重ね、「英語の作成と同時に翻訳を進め、3週間ごとに翻訳の元になるソースファイルを更新する」同意を得ました。この時点で、すべてのドキュメントを翻訳することはできないことが明らかだったため、日本オフィスやパートナー企業からの意見を元に、GAに公開する日本語ドキュメントの数を20強まで減らしました。 急な修正への対応 一般公開が近づくにつれて、英語ドキュメントの更新量が多くなっていきました。予想外な問題が発生することも、連絡もなく突然タイトルが変更になることも増えてきて、そのたびにルジェックは英語ドキュメントの作成者の席にまで行き、問題に対応してきました。「問題が発生してPMに報告すれば、次の日の朝には修正されている」、これもまた非常に理想的な環境です。 大幅な修正が！ 逆に、一番大変だったことは、GA直前にゴールデンウィークがあり、その1週間前に最後の大型更新が発生したことです。蓋を開けてみないと工数がわからないとは言え、直前の大型更新に気が遠くなりながらも、残り時間の少ない中「GA公開」を合言葉に、二人で公開ギリギリまで粘りました。 ついに！ そんなこんなで、5月7日。アメリカ時間午前8時（チェコ時間午後2時/日本時間夜9時）、とうとうその時がやってきました。「英語ドキュメントの公開が始まった」、ルジェックからそんな短いメッセージが届いた直後、英語ドキュメントのPMが英語ドキュメントを公開するのに合わせて、ルジェックが日本語ドキュメントを公開。自宅で待機していた私は、カスタマーポータルで公開されているのを確認。予定されていたドキュメント、無事にすべて英日同時公開です。やった！ こうして、私たちの半年近いプロジェクトがようやく終わりました。 最後に 「読みたいのに日本語がない」、こんな経験が少しでもなくなればとの想いで始めたこのプロジェクトですが、このようにして、私たちは、日本のお客様、パートナー様にいち早く日本語版を届けるという目標を達成できました。次の目標は「定期的な更新」です。引き続き、より多くの方にRHELをご利用いただければと思います。 access.redhat.com

Red Hatの森若です。 Red Hatではソフトウェア開発者むけの Red Hat Developer というサイトを運営しています。今回はこのサイトを紹介します。 developers.redhat.com (更新: 2021年2月8日: 2021年2月1日のTerms更新を反映しました。) (更新: 2024年1月13日: Termsへのリンク追加、組織での利用ができない点を明記しました。) Red Hat Developer って何? Red Hat Developerはもともと、JBoss EAPをはじめとするRed Hatのミドルウェアを利用する開発者を対象としたサイトでした。現在では扱うトピックが広がり、RHEL用のソフトウェア開発や、kubernetes, microservice, DevOpsなど、現在ソフトウェア開発者が必要としているトピック全般を扱うサイトになっていて、 全世界で100万ユーザ以上が登録しています。 何があるの? Red Hat Developerでは開発者むけにさまざまなリソースを提供しています。 一部リソースへのアクセスにはユーザ登録が必要です。 開発者向けリソース Red Hat Developer では開発者むけのさまざまなリソースを提供しています。 how toガイドや技術解説などのblog記事 チートシート 電子書籍 ビデオでの技術解説 その他 いろ いろ 製品へのアクセス https://developers.redhat.com/products/ RHEL, JBoss EAPをはじめとする各種の製品へアクセスできます。 ソフトウェアがダウンロードできるだけでなく、 カスタマーポータル も利用できるので、ナレッジベースへのアクセスも可能になります。 無償のユーザ登録およびRed Hat Developer Programの条件( Red Hat Developer Program Terms and Conditions | Red Hat Developer )への同意が必要です。必ず内容を確認してください。 1年間有効な"Red Hat Developer Suite" のサブスクリプションが付与されます。厳密な条件はDeveloper Program参加時のTerms and Conditionsを確認してください。 1ユーザ(共用不可)、16システムのみに利用できます。 個人での利用限定です。趣味であっても業務であっても問題ありませんが、登録者本人だけが利用・管理するケースに限られます。 複数人の組織での利用はできません。 一部の認定パブリッククラウド へ持ち込むことが可能です 1年経つと失効しますが、失効したあと再度条件(Terms and Conditions)に同意することで継続できます。 どうやって参加するの? アカウント作成はごく普通の手順で困ることはないと思います。アカウントはRed Hatカスタマーポータルと共通になっているので、既にアカウントを持っている人は以下からログインできます(ログイン後条件の確認ページが表示されます)。一旦アカウントを作成すると、GitHub、Google、Twitterなどと連携させてSocial Loginができます。 ユーザ登録 ログイン まとめ Red Hat Developer Program に参加することで、Red Hat がソフトウェア開発者向けに提供している各種のリソースへアクセスできます。早速アカウントを作成して使ってみましょう。

Red Hatでソリューションアーキテクトをしている小島です。 Red Hat Certified Engineer (RHCE) の研修コースについての最新情報をご紹介します。 RHEL8の正式リリースに伴って、RHEL関連の研修コースが刷新されました。 その中でも特に大きく変更されたのがRHCE関連のコースです。 www.redhat.com www.redhat.com RHEL7までのRHCEコースは、ネットワークサービス(DNSキャッシュ/iSCSI/Apache/Postfix/NFS/Samba/MariaDBなど)の設定を中心に扱っていましたが、RHEL8からはAnsibleによる自動化を扱うコース(RH294)になりました。 www.redhat.com RH294のコースを受講いただくことで、システム構築や運用に対する「入力/出力の再現性」を重視したAnsible Automationのスキルを習得できるようになっています。もっとも、その分従来のRHCEコースで扱っていた項目が削除されているのですが、今後それらの項目に対する設定は、対応するAnsibleモジュールを利用して行っていただくようになります。これらを受講者にイメージしていただくために、RH294のコースの中でもRHELの運用に関するモジュールの利用例や公式ドキュメントへのリンクを紹介しています。さらにAdvanced Automationコースとして、 Ansible Best Practiceを扱うコースも近々リリース予定 です。 また、上記FAQページにも記載していますが、従来のRHEL7版RHCEコースもあと1年間ほど提供する予定です。こちらも必要に応じて受講をご検討ください。これらのコースを始めとしたRed Hat各種製品のオンライントレーニングコースを、Red Hat Learning Subscription (RHLS) という形で提供しています。7日間のフリートライアル版もありますので、ぜひともお試しください。 www.redhat.com RHCE関連の研修コースを一通り受けてスキルに自信がついた場合は、Red Hatの認定試験を受講されて対外的にアピールできる資格(RHCSAやRHCEなど)を取得するのもオススメです。RHEL7版のものとなりますが、 Red Hatのサポートエンジニアが記載している記事 も参考にしてください。 補足情報 その1: 適切なAnsible Playbookを書いてシステムに適用すればO.K.というのは分かるんだけど、そうはいっても設定や運用などでトラブった時に原因追求(細かいログを見たりするなど)できるようなスキルを習得したい、という需要もあると思います。そのような方々のために、Red Hat Enterprise Linux Diagnostics and Troubleshooting (RH342) というコースを提供しています。こちらはRHEL7版のコースとなりますが、トラブルシューティングに関する基礎スキルを習得するコースであるため、幅広く応用が効くものになります。RH342はRHLSで受講できますので、こちらの受講もご検討ください。 www.redhat.com 補足情報 その2: また、Red Hat Enterprise Linux 8 New Features for Experienced Linux Administrators (RH354)というコースを提供しています。このコースはRHEL8が正式にリリースされる前から提供しており、RHEL7システムの運営者、管理者、システム主任管理者などの方々が、RHEL8関連のスキルを短期間で習得できるよう、RHEL8のパブリックベータを利用して主要な変更点と新機能を紹介しています。RH354もRHLSで受講できますので、こちらの受講もご検討ください。 www.redhat.com

Red Hatの梅野です。 前回の記事は、タスクの実行に必要なソースをご紹介しましたが、今回はグループとしてタスクの実行を行うケースを見てみましょう。 なぜグループなのか 常に固定的なユーザ（Business Central上ではアクターと表記）にアサインすることは好ましくありません。タスクを行うのは「その役割を担う人」であり、組織として活動をしている会社内では「特定の個人」ではないのです。特定の個人にしていると、骨折した・入院した等で業務が遂行できない場合に、ボトルネックになってしまい、最悪の場合は業務が停止してしまうことになります。 折角RHPAMを導入して業務の効率改善を行うのであれば、タスクは役割を持つ「グループ」にアサインすることをおすすめします。 グループとユーザの設定 グループは複数のユーザが属する事が可能です。Business Centralにadmin権限のあるユーザでログインし、設定（ギアのアイコン）をクリックします。 Business Centralno まずグループを作成します。新規グループ　をクリックしてグループを作成します。 グループの作成 すでに割り当てたいユーザがあれば、ここで割り当てることもできます。ユーザが居ない場合は、ユーザを作成します。 新規ユーザ　をクリックして、ユーザを作ります。 ユーザの作成 ユーザ名を入力します。 ユーザ名入力 次へを押し、右の方にある"グループへ追加" をクリックします。 グループにアサイン あとはテンポラリなパスワードなどを設定して終了です。 Business Centralではこのような手順でユーザ・グループを設定可能ですが、JBoss EAPに慣れている人は、コマンドラインでの追加でも同じことが可能です。CLI インターフェースにて、add-user.sh 等で追加できます。追加されたユーザ情報は、$JBOSS_HOME/standalone/configuration 以下のapplication-users.properties, application-roles.properties に追加されます。 タスクでの設定 プロセス図の中のタスクでは、下記のようにグループを指定します。その際、アクターに名前が指定されていれば外しておきます。 タスクでのグループのアサイン プロセスインスタンスが開始され、該当のタスクに到達すると、自動的にグループにアサインされます。 ステータスの遷移 タスクのステータスは下記の遷移になります。 TastState タスクが特定のアクターに指定されている場合は「予約済み」になりますが、グループに指定されている場合は「使用可能」というステータスになります。そのグループにアサインされている人であれば誰でも、タスクリストに表示される状態です。タスクを実行する場合、まず「クレーム」を行います。クレームはグループからアクターにアサインする操作になります。クレームが行われてアクターにタスクがアサインされると「予約済み」になります。 また、予約済み、もしくは実行中のタスクに対して「リリース」という操作をすると、タスクがグループとして指定されていてもアクターが指定されていても「使用可能」ステータスに戻ります。再度実行する場合は、「使用可能」からクレームを行い「予約済み」にしてから実行します。 実行中に「権限委譲」を行った場合、ステータスは移譲したアクターのタスクリストに入り、ステータスとしては「予約済み」になります。 タスクの実行の結果意図的に失敗としたい場合は、失敗ステータスにすることが出来ます。 絵には記載しませんでしたが、メールを送るタスクでメールの送信に失敗した等の時は、エラーというステータスになり、該当のタスクに紐付けられてJavaのExcpetionが記録されます。 ステータスの遷移についてご紹介しました。直感的にわかるかと思いますが、タスクにおけるステータスの遷移は覚えておくと障害時に対応可能かと思います。 うめの( id:mumeno )

Red Hatの森若です。 今日はタイトル通り、これ以上ないほど簡単にRHEL8を触ってみます。 ブラウザで https://lab.redhat.com/ へアクセスする 最初の"Managing system updates using the web console" のマスにある 「START SCENARIO」 ボタンを押す 」 Welcome! というページがでてくるので 「START SCENARIO」 ボタンを押す Terminalタブが端末で、Web ConsoleタブでRHEL8の新機能の一つであるWeb管理画面にアクセスできます。 この環境はkatacodaを利用したRHEL8の新機能を試すラボで、左側のテキストにそって操作することで、Web Consoleを試すことができます。2 で別のラボを選べば他の機能も試せます。 テキストを無視していろいろいじることもできます。 :-D あくまでラボ用の環境なので制限はありますが、非常に手軽に試せますのでぜひ触ってみてください。

こんにちは、レッドハットでマーケティングを担当している中村( @fideleruuth )です。   Ansibleユーザー会 は、Ansible(Ansible EngineやAnsible Tower, AWX）を使っている、もしくは興味を持っている人たちの集まりです。 実践を通して学んだ気づきなどをみんなでシェアし、アクションを起こすことで、日本のITに従事する人たちがよりよい自動化ライフを送ることを目標とするコミュニティです。技術的なお話だけではなく、自動化を実装するための組織づくりのような観点での情報共有も大歓迎しています。   さて、最近のユーザー会では実際に利用している方のお話を多めにしようと思っており、 「参加者の声」とそれを喋れる「講演者」をマッチングする上 で、過去1年間くらいでAnsible Nightで寄せられた「今後取り上げてほしい内容」を大公開いたします。   結構多いのですが、まとめると、 Ansible Tower/AWX への興味関心が高まっていること、 ユーザー事例 やどのように広めるかのような内容、 ネットワーク自動化 は関心がたかい、という傾向が伺えるかと思います。   また、 初心者向けコンテンツ を求めている方も多くいらっしゃったので、これは「もくもく会」でカバーしているつもりですが、まずは座学から始めたい、というか何からはじめたらいいかわからない、という人が多いのでしょうかね。Ansibleユーザー会に参加する方が大勢いることと、かなり興味範囲に幅がある、かつ限られたリソースで回しているということもあるので、悩ましいところですが、考えて見たいと思います。   こちらのリストは、次のAnsible Nightの企画およびAnsibleユーザーの皆さんの日頃の情報発信の切り口に使っていただければと思います。   取り上げてほしいコンテンツ一覧 カテゴリ Ansible Tower/AWX 事例っぽいもの モジュール ネットワーク 初心者向け Ansible Engine/Playbookまわり 組み合わせ／すみわけ 布教 Windows Galaxy その他   Ansible Tower/AWX Ansible (Tower) サーバの設計 Ansible Tower活用法 ハンズオン形式でAWX触ってみたい AWX と venv追加、AD連携など awx Tower の実用的な使い方。Template や Inventory の現実的な運用方法 Tower or AWX の魅力が知りたいです！ Towerと冗長化の話 towerよろです Tower（AWX）の活用関連 Towerよろです！ ansible-container等追加モジュールをTower・AWXで利用する方法 Ansible tower awxでのserverspec相当のテスト実行について AWX awx! tower Ansible AWXをもう一度。 awx活用事例、network ui Tower/AWX  事例っぽいもの Ansibleの失敗談 Ansible Tower/AWXなしの規模で運用, githubでansible管理 実践的なansible利用事例 ほぼメーカー系の話だったので、もう少しユーザ系の話が聞きたいです。 ハマったところ共有会、アンチパターン共有会、実装してよかったor悪かった内容、といった触ってみた人ならではの共有会 お薦めの利用方法 ansibleで構築した環境のテスト方法　ansible docsに記載のとおり書いたけど動かない事例 ベストプラクティス系は気になりますね。 Ansible を活用した Infrastructure as Code 事例 いろいろみんなの経験ききたい！ 事例紹介 Ansibleの便利な活用方法 運用での導入事例 運用での活用事例 モジュール AnsibleのNWモジュールをユーザとして使っている人のセッションを聞きたい。ここが使いやすい、ここが悪いとかがわかると嬉しい モジュールが見つからないだけなのか、対応するモジュールがないからshell使うべきなのか自分は調査する時間が長くかかっている気がしています。皆さんはどう判断して切り分けているのか知りたいです モジュールつくりかた モジュール開発手法(contribute目指して、特に冪等性担保のありかた・手法・条件など) fileモジュールとかでファイル変更したときのdiffをログに残す等の細かいところ - モジュール開発のような、ちょっとコア寄りな箇所 - Galaxy 追加モジュールの便利性！ クラウド系モジュールで vs Terraformな話   ネットワーク ネットワークオートメーション ネットワーク関連 ネットワーク機器関連 Network Fortinetに関するもの ネットワーク機器の自動化運用(主に検証フェーズ) network運用の具体的な適用事例 Network Automation ネットワーク機器との組合せ ネットワーク系をお願いします！ 引き続きネットワーク自動化の事例など。 ネットワーク装置についての便利な使い方やいい状態確認方法の方法など ネットワーク機器などのエンタープライズな分野との対比として、もう少し個人レベルの環境でも使えるようなテーマ。IoT系とか？   初心者向け もう少し初心者向けのを増やすor初心者向けの会を開催して欲しいです。 101的なもの ド初心者向けの敷居の低い内容も聞かせて頂きたいです。 とても初歩的かもしれませんが、個人的にエラーの原因調査にとても時間がかかったので、そういうクセの部分とかが知りたいと思いました。 Ansible技術的な内容（初心者向け） 初心者向けの企画 みんながAnsibleを使うときにどこを情報ソースとして使っているか   Ansible Engine/Playbookまわり jinja2テンプレート ディレクトリレイアウト、vars命名規則 Ansibleの運用事例 Ansibleのテクニック紹介があれば、嬉しいです verupで追加された機能(2.8以降もLTの時間拡大(10分ぐらい 次期アップデート内容解説 オレのいけてるplaybook自慢 肥大化したPlaybook と闘うには 組み合わせ／すみわけ インフラオーケストレーションツール(ex. Heat, Cloud formation, Terraform) との組み合わせ運用での工夫など Ansibleと他のオーケストレーションツールの組み合わせ Ansibleと監視アプリの役割分担・共存 TerraformとAnsibleの住み分け   布教 Ansible普及活動事例について（なかなか同僚がついてこない、管理職達がAnsibleになぜか懐疑的なので普及活動がすすまない、、） 周りへのAnsible布教の仕方 ・引き続きNW機器のAnsible化のお話 チームや組織にAbsibleを広めたよっていう成功談が聞きたい 組織的にansibleを運用するノウハウ   Windows windowsサーバへの利用 WindowsのGUIの自動化 windowsモジュール Galaxy Ansible-galaxyの便利な使い方 galaxy活用法 ansible galaxyについて Galaxy role の品質 その他 Dockerとの関わりについて 異機種環境での活用とか OS や vendor ごとの module を wrap するツールなどがあれば、聞きたい Ansibleの拡張方法など 試験の自動化、ストレージ装置の設定自動化 ロールのテスト方法、組織でのプレイバック・ロール管理など マイベストvars配置場所の様なナレッジ共有系のLTを色んな人から聞いて見たいです！ テスト自動化 testまわりかなあ インフラCI, IaC もう少し深いci周り DevOps アジャイル AWS!! コンテナの話 レガシー環境との兼ね合い オンプレとクラウド連携自動化など OpenStack、OpenShift、ベアメタルなどのIaaS構築 自動化の話はやっぱり面白いので聞きたいです Ansibleを使ったAMI作成の自動化 Makoto is very handsome   さいごに Ansible Towerに関してのご要望が多かったのですが、Ansible Towerの評価は以下のサイトからリクエストができますので、もしもご自身の環境で試してみたいなというかたはぜひ以下からお申し込みください。日本語のドキュメントもちゃんとありますよ。 www.ansible.com   docs.ansible.com   Ansibleに関する日本語情報は以下で随時アップデートしていますので、ご参照下さい。 www.redhat.com   ハッピー・オートメーション！

Red HatでOpenShiftのサポートをしている id:nekop です。OpenShift 4.1が本日リリースされたので、インストールしてみます。 docs.openshift.com 今回はAWSを利用して一番簡単なほぼ全自動のIPI(インストーラによるインフラ作成インストール)というインストールを行います。IPIではRed Hat CoreOSが利用されます。IPIの他に、ホストなどを自前で用意するUPI(ユーザによるインフラ作成インストール)というインストール方法もあります。 AWS IPIではRoute 53上で管理可能なPublic Domainが必要なので、ドメインを取得する、もしくは所持しているドメインのサブドメインをRoute 53に作成して、親ドメインから委任設定する必要があります。下記例示に利用している shift.example.com は実際には存在しないドメインです。 最初に install-config.yml を作成して、バックアップを作成しておきます。 install-config.yml ファイルはインストール実行時に消去されるので、インストールを試行錯誤する場合に取っておいたほうがラクです。個人的には実際には git init してGitで管理しています。 $ ./openshift-install create install-config ? SSH Public Key /home/nekop/.ssh/id_rsa.pub ? Platform aws ? Region ap-northeast-1 ? Base Domain shift.example.com ? Cluster Name tkimura ? Pull Secret [? for help] ***** # ダウンロードしたpull secretをここにコピー＆ペースト $ cp -a install-config.yml{,org} 自分が利用しているAWSアカウントでは、 ap-northeast-1a が Capacity Constrained だそうで、subnetが作成できないなどの利用制限があったので install-config.yml をカスタマイズして利用するゾーンを指定します。 install-config.yml には platform という項目が3回出現しますが、それに全て以下のようにzonesを指定します。 platform: aws: zones: - ap-northeast-1c - ap-northeast-1d 編集して上記を反映、再バックアップします。 $ vi install-config.yml $ cp -a install-config.yml{,.modified} クラスタを作成します。このステップは30分程度かかりますが、基本的に何もすることはなく待っているだけです。デフォルトで3 masters 3 nodes構成ですが、mastersの数はよっぽどのことがない限り3で問題ないですし、nodesの数は oc scale machineset tkimura-xxxxx-worker-ap-northeast-1c --replicas=5 というようなオペレーションでいつでも増減できるのであまり気にしなくて良いです。 $ ./openshift-install create cluster INFO Creating infrastructure resources... INFO Waiting up to 30m0s for the Kubernetes API at https://api.tkimura.shift.example.com:6443... INFO API v1.13.4+838b4fa up INFO Waiting up to 30m0s for bootstrapping to complete... INFO Destroying the bootstrap resources... INFO Waiting up to 30m0s for the cluster at https://api.tkimura.shift.example.com:6443 to initialize... INFO Waiting up to 10m0s for the openshift-console route to be created... INFO Install complete! INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/nekop/ocp4/auth/kubeconfig' INFO Access the OpenShift web-console here: https://console-openshift-console.apps.tkimura.shift.example.com INFO Login to the console with user: kubeadmin, password: xxxxx-xxxxx-xxxxx-xxxxx インストールの各フェーズにかかった時間はおおむね以下となりました。 masterとbootstrap、基本インフラ作成 7分 (うちamiコピー5分) master/etcdの起動完了 10分 bootstrap完了 5分 クラスタオペレータの完了(ワーカーノード起動も含む) 9分 インストーラーは最初に3 mastersと1つのbootstrapというインスタンスを作成します。OpenShift 4では、masterが自律的にmasterの設定やアップデートを行うようになっていますが、最初のmasterが存在しない状態では何も実行できないので、bootstrapという初期設定を行うmasterが実行され、bootstrapによって最初の3 mastersが設定されます。 最後にインストール時のログを抜き出したものを載せておきます。 time="2019-06-04T15:33:46+09:00" level=debug msg="OpenShift Installer v4.1.0-201905212232-dirty" time="2019-06-04T15:34:08+09:00" level=info msg="Creating infrastructure resources..." time="2019-06-04T15:34:23+09:00" level=debug msg="aws_ami_copy.main: Creating..." time="2019-06-04T15:39:42+09:00" level=debug msg="aws_ami_copy.main: Creation complete after 5m18s (ID: ami-0673c877e07ae917b)" time="2019-06-04T15:40:42+09:00" level=debug msg="Apply complete! Resources: 109 added, 0 changed, 0 destroyed." time="2019-06-04T15:40:42+09:00" level=info msg="Waiting up to 30m0s for the Kubernetes API at https://api.tkimura.shift.example.com:6443..." time="2019-06-04T15:50:54+09:00" level=info msg="API v1.13.4+838b4fa up" time="2019-06-04T15:50:54+09:00" level=info msg="Waiting up to 30m0s for bootstrapping to complete..." time="2019-06-04T15:55:44+09:00" level=debug msg="Bootstrap status: complete" time="2019-06-04T15:55:44+09:00" level=info msg="Destroying the bootstrap resources..." time="2019-06-04T15:56:29+09:00" level=debug msg="Destroy complete! Resources: 12 destroyed." time="2019-06-04T15:56:29+09:00" level=info msg="Waiting up to 30m0s for the cluster at https://api.tkimura.shift.example.com:6443 to initialize..." time="2019-06-04T16:07:56+09:00" level=debug msg="Cluster is initialized" time="2019-06-04T16:07:56+09:00" level=info msg="Install complete!" これでインストールは完了です。インストールプロセスの詳細などは以下のblogが詳しいです。 blog.openshift.com Red Hatでは運用が簡単なKubernetesディストリビューション製品OpenShiftを一緒に育てるエンジニアを募集しております！ https://global-redhat.icims.com/jobs/68813/software-maintenance-engineer---openshift/job global-redhat.icims.com

Red HatでOpenShiftのサポートをしている id:nekop です。RHEL 8がリリースされたので、いろいろな用途に使っている自分用のお仕事RHEL 7サーバVMをRHEL 8ベースへとお引っ越ししました。 まずはRHEL 8サーバVMを起動して、基本的なツール群をインストールします。VMのブートや subscription-manager の手順は省きます。 yum install -y pcp-zeroconf pcp-system-tools sos sysstat podman skopeo buildah git lsof strace tcpdump bash-completion Insights を有効化しておきます。 yum install -y insights-client insights-client --register このサーバで動作しているネットワークサービスはNFS (OpenShiftのNFS PVテスト用), Nexus (Javaアプリをビルドするときのjarファイルのローカルキャッシュ), Container Registry (OpenShiftの外部コンテナレジストリテスト用), ZNC (IRC bouncer), Squid (OpenShiftのプロキシ環境テスト用)です。OpenShiftのサポート業務でこれらが自分のコントロール下にあることで、生産性が大きく向上します。 まずNFSサーバですが、NFSサーバはカーネル空間で動作するため残念ながらコンテナ化できません。普通にセットアップします。 yum install -y nfs-utils mkdir -p /exports chown nobody.nobody /exports chmod 777 /exports cat <<EOF > /etc/exports /exports *(rw) EOF systemctl enable nfs-server --now firewall-cmd --add-service nfs firewall-cmd --runtime-to-permanent NFSサーバが正しく動作していることを確認します。 mkdir -p /mnt/test mount $(hostname):/exports /mnt/test touch /mnt/test/testfile ls -l /exports rm /mnt/test/testfile umount /mnt/test NFS以外はコンテナにしない理由がないので、基本的に全てコンテナにします。Nexus, Container Registry, ZNCはとりあえずオフィシャルイメージを使います。セキュリティ要件によってはイメージのリビルドを行ったほうが良いでしょう。 以下のような感じでsystemdのunitファイルを記述します。動作ユーザは全て自分のユーザnekop(uid 1000)にしておきます。同様に docker.io/library/znc , docker.io/library/registry:2 も動作させます。 sudo -u nekop mkdir -p /home/nekop/nexus-data cat <<EOF > /etc/systemd/system/nexus.service [Unit] Description=Nexus After=network-online.target Wants=network-online.target [Service] Type=simple ExecStartPre=-/usr/bin/podman stop nexus ExecStartPre=-/usr/bin/podman rm nexus ExecStartPre=/usr/bin/podman pull docker.io/sonatype/nexus ExecStart=/usr/bin/podman run --name nexus --user 1000:1000 -p 8081:8081 -v /home/nekop/nexus-data:/sonatype-work:Z docker.io/sonatype/nexus ExecStop=/usr/bin/podman stop nexus [Install] WantedBy=multi-user.target EOF Squidについてはそのまま使えそうなコンテナが見当たらなかったので、コンテナイメージを作ります。Squidをフォアグラウンドで普通に起動させても良いのですが、今回はお手軽にubi8-initコンテナでコンテナ内systemdで起動する、という方法を採用します。 以下コンテナビルドはRHEL 8上でroot権限での操作です。squidパッケージはRHELのrpmチャネルにあってubiチャネルにはありません。RHELのrpmチャネルにアクセスするためには、RHELホスト上rootでのコンテナビルドが必要です。 podman loginに利用するサービスアカウントのユーザ名とパスワードは Registry Service Accounts から取得してください。 コンテナ内systemdを利用するためには setsebool container_manage_cgroup=on 設定が必要です。この設定をしておかないと、コンテナで /sbin/init が起動するけどsystemdが動作せず何も起きない、という結果になります。 podman login registry.redhat.io podman pull registry.redhat.io/ubi8-init buildah from --name squid-work registry.redhat.io/ubi8-init buildah run squid-work dnf install -y squid buildah run squid-work systemctl enable squid buildah commit squid-work squid setsebool container_manage_cgroup=on 他にも ubi8-minimal や ubi8 コンテナベースにしてビルドもしてみたのですが、イメージによっては起動確認しようと思ってexecしてコンテナ内からpsコマンドを実行したらpsコマンドが無かったりして少し戸惑いました。 podman top squid などとするとプロセス一覧が取得できるのでそちらで代用できます。 Squidのsystemd unitファイルを作成します。コンテナ内systemdを利用するには --stop-signal SIGRTMIN+3 指定が必要なのと、uid指定は削除してデフォルト設定にする必要があります。systemdにはコンテナ内のroot権限が必要となり、uid指定でノーマルユーザを指定するとsystemdが起動しません。 cat <<EOF > /etc/systemd/system/squid.service [Unit] Description=Squid After=network-online.target Wants=network-online.target [Service] Type=simple ExecStartPre=-/usr/bin/podman stop squid ExecStartPre=-/usr/bin/podman rm squid ExecStart=/usr/bin/podman run --name squid -p 3128:3128 --stop-signal SIGRTMIN+3 localhost/squid ExecStop=/usr/bin/podman stop squid [Install] WantedBy=multi-user.target EOF 最後にまとめて起動して、外部接続の許可を行っておしまいです。 systemctl daemon-reload systemctl enable nexus znc registry squid --now firewall-cmd --add-service irc firewall-cmd --add-service squid firewall-cmd --add-port 5000/tcp firewall-cmd --add-port 8081/tcp firewall-cmd --runtime-to-permanent 実際にはマイグレーションにあたってznc.confの設定の見直しをしていたり、既存のデータをrsyncする、DNSのレコードの切り替え、といった雑多な作業が他にも発生していますが、4時間程度で既存のRHEL 7サーバをRHEL 8に移行することができました。

こんにちは。先日、Red Hat Tech Night のライトニングトークでラボ環境にOpenShift on OpenStack が欲いと呟いた、ソリューションアーキテクトの荒木です。 今回は、 以前の記事で紹介したArchitecture Design Patterns に、新たに、パターンを追加致しましたので、紹介します。 今回作成したパターンは、RHOSP上で、ファイル共有サービス(manila)機能を有効にするものです。 パターンの詳細は、 こちら「企業プライベートIaaS ファイル共有サービス(CephFS NFS-ganesha) 構成」 ファイル共有サービス OpenStackで実装されているファイル共有サービス(manila)は、文字通り、VMインスタンスに対して、ファイル共有サービスを提供するものです。 manila project wiki manilaは、ファイル共有サービスそのものの提供に加えて、ファイル共有サービス利用に必要となるAPI群を提供します。例えば、ボリュームの作成／削除や、アクセス許可といった、ストレージそのものへの設定操作を抽象化しています。 尚、実データの読み書きや、データの可用性（RAID等を使用したデータの冗長化）については、バックエンドのストレージの機能に委ねられています。 manila アーキテクチャ概要 VMインスタンス( ユーザ）から、ファイル共有サービスへのアクセスを図示すると、下記のようになります。 VMインスタンスは、controller ノード上のNFS-ganesha と、NFS v4 で接続します。 NFS-ganesha は、CephFSで、ceph-osd とデータのやり取りをします。 その他、各種、ファイル共有領域にの作成といった管理操作に関するリクエストは、manila api によって処理され、manila share service によって、ストレージ上の領域が管理される動作となります。 ADP構成のポイント 今回の構成では、下記のポイントがあります。 ファイル共有サービスのストレージバックエンドをceph としている データアクセストラヒック専用ネットワークを用意している RHOSPのストレージバックエンド ADP構成では、Red Hat Ceph Storage を RHOSP全体のストレージバックエンドとして使用する構成となっています。ファイル共有サービスのデータ領域についても、Ceph Storage に集約する構成となります。 主な機能と、Ceph Storage のI/F をまとめると下記のようになります。 機能/機構 Ceph I/F 備考 Block Volume ( cinder ) librbd Block Volume Backup ( cinder-backup ) librbd デフォルトはSwift Image ( glance ) librbd デフォルトはSwift nova boot-disk librbd デフォルトはcompute のローカル meterling ( ceilometer ) librados gnocchi のバックエンド Object Store ( swift ) librados ADPでは、rados は未組込 File Shareing ( manila ) libcephFS nfs-ganesha - CephFS 間は、ネイティブ ネットワーク構成 ネットワークの接続は、下記の図のようになります。 図の"StorageNFS(紫線)"が、クライアントと、NFS-ganesha との通信で使用されるネットワークとなります。これは、 製品ドキュメント で紹介されているネットワーク構成をそのまま踏襲した接続方法となっています。 尚、StorageNFS は、プロバイダーネットワークとして構築され、VMインスタンスは、StorageNFS のVLANへNICを接続し、アクセスする形となります。 構築時の注意点 構築方法の詳細は、ADP をご確認いただければと思いますが、オーソドックスな構築パターンと比べて、幾つか、特殊な機能を使用しているので、簡単に紹介します。 カスタムのロール定義 ネットワーク定義の拡張 overcloud deploy コマンド overcloud deploy コマンドは、下記となります。 time openstack overcloud deploy --verbose \ --templates /usr/share/openstack-tripleo-heat-templates \ -n /usr/share/openstack-tripleo-heat-templates/network_data_ganesha.yaml \ -r /home/stack/templates/roles_data.yaml \ -e /home/stack/templates/global-config.yaml \ -e /home/stack/templates/cloud-names.yaml \ -e /home/stack/templates/scheduler_hints_env.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/docker.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml \ -e /home/stack/templates/overcloud_images.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/net-bond-with-vlans.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-management.yaml \ -e /home/stack/templates/network-environment.yaml \ -e /home/stack/templates/ips-from-pool-all.yaml \ -e /home/stack/templates/ceph-storage-environment.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-mds.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsganesha-config.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml \ --timeout 210 \ --ntp-server ntp.nict.jp \ --log-file ./overcloud_deploy.log \ --stack $stack_name テンプレートを指定する場合、通常は、-e オプションの後に、読み込ませる yamlファイルを指定しますが、今回は、-n オプションと、-r オプションを用いて、特殊な定義をしています。 それぞれのオプションの意味 -n : overcloud のネットワーク構成を、デフォルトから上書きする場合に指定 ... 今回は、StorageNFS セグメントの定義 -r : node の役割(compute , controller ...etc) を、拡張する場合に指定 ... 今回は、ControllerStorageNfs というカスタムロールを定義 ロール(役割)は、製品として予め定義されています(compute , controller , swift ...etc) 。これらのロール定義の作用は、overcloudを構築する際に、node(物理マシン)に対して、どのOpenStackのコンポーネントを配置するかというマップ情報となります。使い方を例えると、デフォルトで、「controllerノードの機能として定義されている、SwiftStorage 機能を、切り離して、swift専用のロールを定義する」という様になります。この例が期待するところは、オブジェクトストレージサービスをcontroller から分離する事で、controllerが、3台配置が上限である点に対して、SwiftStorage機能をより多い台数で構成できることです。 カスタムロールの詳細は、 RHOSP director がもつ機能 をご覧ください。 (注意)カスタムロールは、極端な使い方をすれば、全ての機能を単一のロールに集約したり、逆に、全ての機能を別々のnode に分解したりもできうる仕組みですが、任意の構成が実際に構築できることと、その構成サポートされるか否かは別の問題となりますので、カスタムロールを使用して機能の配置を検討される場合は、Red Hat までご相談ください。 manila の使用感 manila の使い方を紹介する動画を用意しましたので、こちらも合わせてご覧ください。 まとめ 今回は、ADP の新しいパターンとして、ファイル共有サービス（デフォルトでは無効化されている）機能を有効化した構成を紹介しました。機能を拡張／カスタマイズする上で、標準的なオプション意外に、"-n" でネットワーク定義を拡張したり、"-r" でロールを拡張／変更したりする方法について、ここで簡単に紹介しました。 おわりに カスタムロール(-r)や、コンポーサーブルネットワーク(-n) は、比較的、最近実装された機能となりますが、使いなれる事によって、より構成の自由度が上がるため、より自分好み（要件にそった）OpenStack 環境を構築する上では、重要なテクニックであると思います。 他方、RHOSP で新しい構成を為す場合、以前は、度重なるトライ＆エラー(社内では、『素振り』と呼んでいます(笑))を伴うのが常なのですが、今回はとてもスムーズに進めることができました。 CEPHFS VIA NFS BACK END GUIDE FOR THE SHARED FILE SYSTEM SERVICE ように、構成方法に関する情報がきちんと用意されるようになった現在は、数年前の圧倒的に情報が不足していた時期と比べて、製品の品質と安定度が向上してきているのだなと実感しました。

Red Hatソフトウェアエンジニアの佐藤匡剛です。 昨晩の RHTN #2 にお越しいただいた皆様、ありがとうございました。自分が担当したLTのスライドはこちらにアップロードしました。 Red Hat Tech Night 2019.5 - Camel 3 and Beyond... from Tadayoshi Sato www.slideshare.net しかし、さすがに5分というのはちょっと話し足りなかった（かつ最近は引き篭もっていて滑舌悪く上手く話せなかった）ので、こちらで少し補足したいと思います。 Camel 3の注目ポイント 今回のLTの目玉だったので、スライドをそのまま再掲します。 後方互換性の維持 camel-core の軽量＆モジュール化 API 整理＆技術負債の解消 型安全な Fluent Builder エンドポイント定義の導入 新しいクラウド EIP パターン Quarkus エクステンション Camel-K （前回 RHTN の元ネタ） Java 11 サポート タイムボックスリリース 新しいウェブサイト／ドキュメント 後方互換性の維持 なるべくCamel 2ベースのアプリを壊さないように、とはいえ、やはりメジャーアップグレードなのでそれなりに変わります。Camel 2 -> 3のマイグレーションガイドは以下になります。 Apache Camel 3 Migration Guide すでにCamel 3.0.0 M2がリリースされていますので、興味ある方はこのガイドをたよりにさっそくCamel 3を試してみましょう！ Fluent Builderエンドポイント この時点で4分の鐘が鳴ってしまい、あせってほとんどお話できなかったのですが、Camel 3の注目機能の1つになるかなと思います。 元々、昨年のブログでAkka / AlpakkaとCamelを比較するという記事が界隈で少し話題になったことがあって、その中でAkka / Alpakkaとの比較で「Camelは全然型安全じゃないじゃん！」と煽られたことがありました（笑）。 www.thedevpiece.com それに対するCamelコミュニティからの返答が、このFluent Builderエンドポイントになります。これまでのCamelは、エンドポイントURLがすべてテキストベースでコンパイル時の型チェックが出来なかったのですが（一応、その代わりIDEのプラグインでパラメータをチェックしてくれるツールが豊富に揃っています）、 from( "file:inbox?recursive=true&withDelay=2000" ) .to( "jms:queue:cheese?withTimeToLive=5000" ); それをこのようにメソッドチェーンでも定義できるようにしよう、というものです。 from(file( "inbox" ).recursive().withDelay( 2000 )) .to(jms( "cheese" ).withTimeToLive( 5000 )); こうすると、IDEのコード補完でより簡単にエンドポイント定義ができるようになるだけでなく、パラメータの型チェックまで出来るのでより安全かつ便利になります。 しかし、来月リリース予定のM3ではまだこの機能は完成しておらず、かなり大変な作業が残っているはずなので、本当にGAリリースまでに載ってくるのかちょっと心配ではあります。 Camel meets Quarkus 最後に、デモでチラッとだけお見せしたQuarkusエクステンションの話をちょっとだけしたいと思います。 Quarkusについては、須江さんのLTで紹介もあったようにまずはGet Startedガイドから始めてみるといいと思います。 quarkus.io Quarkusは基本的にMaven（またはGradle）コマンドを使って開発していくんですが、以下のMavenコマンドで現在サポートされているエクステンションのリストを見ることができます。 $ mvn quarkus:list-extensions ... Current Quarkus extensions available: Status Extension ArtifactId Updated Version Guide ... current Camel Core quarkus-camel-core 0.15.0 Camel Infinispan quarkus-camel-infinispan Camel Netty4 HTTP quarkus-camel-netty4-http Camel Salesforce quarkus-camel-salesforce ... 見ての通り現時点ではまだ4つのCamelコンポーネントに対してしかエクステンションがありません。これをGAまでにもっと拡充させていく予定です。とはいえ、camel-coreとHTTP（camel-netty4-http）だけでもある程度のことは出来るので、現時点でもそれなりに遊ぶことはできます。 QuarkusアプリにCamelのエクステンションを追加するには、以下のMavenコマンドを実行します。 $ mvn quarkus:add-extension -Dextensions="quarkus-camel-core" LTで紹介したCamel + Quarkusデモのソースコードはこちらです。 https://github.com/tadayosi/quarkus-hello

レッドハットでコンサルティングしているフェンです。 今回は、swagger-uiをFuseアプリケーションに埋め込み、APIドキュメント(WebAPI仕様書)を簡単に公開するサンプルと設定内容を紹介します。 このサンプルでは、 Swagger UI を使用して、 RES DSL で定義されたAPIのAPIドキュメント(WebAPI仕様書)を表示します。 ソースコードはGithub（ https://github.com/jian-feng/camel-restdsl-swagger-demo.git ）からダウンロードできます。 サンプルアプリの構造 Swagger UIとCamel REST DSL Swagger とは、RESTful APIのドキュメントや、サーバ、クライアントコード、エディタ、またそれらを扱うための仕様などを提供するフレームワークであります。 Swagger UI とは、 Swagger Specification から動的にドキュメントを生成するツールです。 RES DSL とは、CamelルートでREST APIを記述するDSLです。 因みに、REST DSLでREST APIを開発する方法は、これらの記事をご参照ください。 Creating a REST API in Apache Camel Get started with REST services with Apache Camel 29行でメール送信サービスを作る - Apache Camel 今回は、REST DSL開発ではなく、 主にSwagger UI連携するための設定 を説明させてください。 サンプルの実行方法 Mavenコマンドで実行します。 mvn spring-boot:run そして、ブラウザでサンプルアプリで公開されるSwagger UIを表示できます。 http://localhost:8080/webjars/swagger-ui/3.22.0/index.html?url=/camel/api-docs swagger-ui サンプルの設定内容 Step 0. Swagger UIの組み込み pom.xml にSwaggerライブラリを追加します。 <!-- Swagger support for restdsl --> <dependency> <groupId> org.apache.camel </groupId> <artifactId> camel-swagger-java-starter </artifactId> </dependency> <dependency> <groupId> org.webjars </groupId> <artifactId> swagger-ui </artifactId> <version> ${swagger.ui.version} </version> </dependency> Step 1. REST Configuration Camel提供のSwagger設定項目を使用して、API全体の概要情報をRest configuration( camel-context.xml の <restConfiguration> )に記述します。 例: <restConfiguration apiComponent = "swagger" apiContextPath = "/api-docs" component = "servlet" contextPath = "/camel" enableCORS = "true" host = "0.0.0.0" port = "8080" > <dataFormatProperty key = "prettyPrint" value = "true" /> <!-- 設定可能なapiProperty一覧は、Swaggerドキュメントを参照 --> <!-- http://swagger.io/specification/#infoObject --> <apiProperty key = "api.title" value = "My REST API" /> <apiProperty key = "api.version" value = "1.0.0" /> <apiProperty key = "api.description" value = "APIドキュメントのデモ" /> <apiProperty key = "api.contact.name" value = "フェン　ジン" /> <apiProperty key = "api.contact.email" value = "jfeng@redhat.com" /> </restConfiguration> apiComponent , apiContextPath enableCORS は、Swagger有効化ため最低限の設定。他に設定可能な内容は、 こちら を参照してください。 <apiProperty> は、API情報(infoObject)の設定。他に設定可能な内容は、 こちら を参照してください。 Step 2. REST Context Camel提供のSwagger設定項目を使用して、個々のAPIの詳細(例、要求／応答のデータタイプなど)をRest context( camel-context.xml の <rest> )に記述します。 Rest contextを別XMLで記述し、Camel-context.xmlにてincludeすることもできます。 例: <rest bindingMode = "off" id = "rest-1" path = "/restsvc" > <description> sample rest service </description> <get id = "get-1" uri = "/ping" > <description> This is ping service </description> <responseMessage code = "200" message = "要求情報が正常に処理され、HelloメッセージがJSON形式で返す" responseModel = "org.mycompany.ResponseInfo" /> <responseMessage code = "500" message = "要求情報に問題がないが、サーバ側で処理異常のため、ErrorメッセージがJSON形式で返す" responseModel = "org.mycompany.ErrorInfo" /> <route> <to uri = "direct:hello" /> </route> </get> </rest> <description> , <responseMessage> は、Swagger有効化ため最低限の設定。他に設定可能な内容は、 こちら を参照してください。 Step 3. DataModel Swagger Coreのモデルプロパティ定義（@ApiModelProperty）アノテーションを使って、個々のDataModelに補足情報を追加します。 要求・応答情報のデータモデルやリソースモデル内で定義している各プロパティに @ApiModelProperty を用いて、プロパティの説明や入力例、プロパティの表示順序などを設定できます。以下は主要なメソッドを説明します。 メソッド 説明 value プロパティ名を指定します。 required プロパティが必須かどうかを指定します。 (default: false) example プロパティの入力例を指定します。 position プロパティの表示順序を指定します。 (default: 0) 例: src/main/java/org/mycompany/ResponseInfo.java import io.swagger.annotations.ApiModelProperty; public class ResponseInfo { @ApiModelProperty (value = "Hello msg from camel" , required = true , example = "sample message" ) private String msg; public String getMsg() { return msg; } public void setMsg(String msg) { this .msg = msg; } } 終わりに CamelのREST DSLで開発されるAPIはcamel-swaggerを介して、APIドキュメントを公開する方法を理解できたでしょうか。APIの開発時に、ソースコード上でコメントだけでなく、公開可能なAPI情報も意識して埋め込めば簡単に情報共有できます。このため、開発標準の一環として取り入れてください。

こんにちは、Red Hat でストレージを中心にクラウドインフラを生業にしている宇都宮です。 さてみなさん、「ちょっとしたオブジェクトストレージが作りたいなあ」なーんて思ったことはありませんか？オブジェクトストレージを扱うアプリケーションを開発してる方とか。OpenShiftみたいなCloud Nativeなプラットフォームを作ってる方とか。バケットの事を考えると眠れなくなるほどオブジェクトストレージが好きで伝説の樹の下で…ｺﾞﾆｮｺﾞﾆｮ え？本家のS3を使うから大丈夫？確かにそれは一つの答えです。ですが安いとは言えお金がかかるし、インターネットを超えるからスループットやレスポンスは落ちるし、できればオンプレがいいなあ、みたいな。 "ちょっとしたファイルストレージ" ならサクッとNFSサーバーを建てれば当面解決できるんですけどね。オブジェクトストレージはそういうのがあまり無いんですよね。かと言って割としっかりオブジェクトストレージを作ろうとするとそれなりにリソースの準備が要るのでハードルが高い。ここはNFSサーバー並みのお手軽さが望ましい。 そういうわけで、前置きが長くなりましたが今回はNFSサーバー並みにお手軽に作るオブジェクトストレージを紹介します。Ceph Nanoです。 Ceph Nanoとはなんぞ Ceph Nanoとは、その名の通りオープンソースSDSの Ceph を元にした超小型オブジェクトストレージを実現するソフトウェアです。 github で公開されていて誰でも入手して使えます。 github.com 元のCephはデータの冗長化やシステムの耐障害性を上げるため少なくとも3つ以上のノードでストレージクラスターを組むことが一般的ですが、Ceph Nanoは1つだけです。しかもあなたのPCでも稼働できるほどの激軽さです。Linuxの他に、MacでもOK。 あ、Ceph Nanoは元のCephとは違ってブロックストレージやファイルストレージとしては使えないので注意して下さいね。 さっそくCeph Nanoをインストールしてみよう 基本的には先のgithubのREADMEを読めば分かるんですが、めっちゃ簡単なのでここで追っていきましょう。 0. コンテナの実行環境を用意する Ceph NanoはCephストレージをコンテナで作るのでコンテナ実行環境を用意します。コンテナの実行環境についてはやいやい声が聞こえてくるところですが、githubのインストール手順にしたがってDockerを用意しましょう。 [utubo@tutsunom ~]$ sudo systemctl start docker [utubo@tutsunom ~]$ sudo systemctl status docker ● docker.service - Docker Application Container Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; disabled; vendor preset: disabled) Active: active (running) since Thu 2019-05-09 13:05:31 JST; 2s ago Docs: http://docs.docker.com Main PID: 19612 (dockerd-current) Tasks: 15 (limit: 8192) Memory: 45.7M CGroup: /system.slice/docker.service └─19612 /usr/bin/dockerd-current --add-runtime oci=/usr/libexec/docker/docker-runc-current --default-runtime=oci --authorization-plugin=rhel-push> ... [utubo@tutsunom ~]$ docker -v Docker version 1.13.1, build 1185cfd/1.13.1 1. githubからcnのバイナリをダウンロードする Ceph Nanoは基本的にcn(ceph nanoの略ね)というバイナリを使っていろいろ操作します。 ここ に使うマシン毎にcnのバイナリがあるので、サクッとダウンロードしましょう。 僕マシンはfedora 28なのでLinux amd64を。 [utubo@tutsunom ~]$ curl -L https://github.com/ceph/cn/releases/download/v2.3.0/cn-v2.3.0-linux-amd64 -o cn && chmod +x cn % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 612 0 612 0 0 1026 0 --:--:-- --:--:-- --:--:-- 1026 100 12.0M 100 12.0M 0 0 742k 0 0:00:16 0:00:16 --:--:-- 1939k [utubo@tutsunom ~]$ 2. 試しにcnを叩いてみる。 [utubo@tutsunom ~]$ ./cn Current version: v2.3.0 Latest version: v2.3.0 Ceph Nano - One step S3 in container with Ceph. *((((((((((((( ((((((((((((((((((( ((((((((* ,(((((((* (((((( (((((( *((((, ,((((/ ((((, ((((((/ *(((( (((( ((((((((( (((( /((( ((((((((( (((( (((. ((((((( /(((/ ((( *(((( .((( ((((( ,(((((((* /((( .((((( ((( (/ // ((( /(((. /((((( /((((( .((((/ (/ Usage: cn [command] ... イヤァオ！チビタコのAAがきゃわわ！ あれ、終わり？Dockerは？っていうお客様。トランキーロ。これからです。 3. Cephクラスターを実行する。 cnを使ってCephのコンテナを実行します。最初はイメージをダウンロードする時間が数分かかります。 ってかCephのコンテナイメージってどんなのがあんの？というのもcnを使って調べられます。 [utubo@tutsunom ~]$ ./cn image ls ceph/daemon:latest-bis ceph/daemon:latest-bis-nautilus ceph/daemon:latest-bis-mimic ceph/daemon:latest-bis-luminous ceph/daemon:master-11bc88f-mimic-centos-7-aarch64 ceph/daemon:master-11bc88f-luminous-centos-7-aarch64 ceph/daemon:latest-bis-master ceph/daemon:latest ceph/daemon:latest-nautilus ceph/daemon:latest-mimic ceph/daemon:latest-luminous ceph/daemon:latest-master ceph/daemon:master-11bc88f-mimic-centos-7 ceph/daemon:master-11bc88f-luminous-centos-7 ceph/daemon:master-11bc88f-luminous-opensuse-42.3-x86_64 ceph/daemon:master-11bc88f-master-centos-7-x86_64 ... めっちゃ出てくるので↑では省略してますが、 dockerhub にあるlatest-*とmaster-*のタグが付いたイメージが列挙される感じです。 多いよもう、どれがいいんだよ。って思いますよね。僕もそう思う。そんな時は、ひとまずこれがいいんじゃない？というのもcnで出てきます。 [utubo@tutsunom ~]$ ./cn image show-aliases +----------+--------------------------------------------------+ | ALIAS | IMAGE_NAME | +----------+--------------------------------------------------+ | luminous | ceph/daemon:latest-luminous | | mimic | ceph/daemon:latest-mimic | | redhat | registry.access.redhat.com/rhceph/rhceph-3-rhel7 | +----------+--------------------------------------------------+ とりあえず3つに絞れた。お、Red Hat Ceph Storageのイメージも出てきますね。せっかくだから、俺はこの赤い扉を選ぶぜ！とばかりにこいつを選んでみましょう。Red Hat Ceph StorageのサブスクリプションがなくてもOKよ！ [utubo@tutsunom ~]$ ./cn cluster start desusama -i redhat The container image (registry.access.redhat.com/rhceph/rhceph-3-rhel7) is not present, pulling it. This operation can take a few minutes. .................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................... 2019/05/10 10:15:45 Running cluster desusama | image registry.access.redhat.com/rhceph/rhceph-3-rhel7 | flavor default {512MB Memory, 1 CPU} ... Endpoint: http://172.20.10.2:8000 Dashboard: http://172.20.10.2:5000 Access key: 8C072B46WQA5945CB6K9 Secret key: nCt4TNicHXHkkq0uNqpbsMWX6UKCjHfsvPVNYEWX Working directory: /usr/share/ceph-nano イヤァオ！ これでS3 compatibleなオブジェクトストレージができました。 ちなみにEndpointやAccess keyなどの情報は、 ./cn cluster status でいつでも確認できるので心配なく。 [utubo@tutsunom ~]$ ./cn cluster status desusama Endpoint: http://172.20.10.2:8000 Dashboard: http://172.20.10.2:5000 Access key: 8C072B46WQA5945CB6K9 Secret key: nCt4TNicHXHkkq0uNqpbsMWX6UKCjHfsvPVNYEWX Working directory: /usr/share/ceph-nano ではオブジェクトをPUTしてみよう S3クライアントは世間にたくさんあるので何を使ってもいいんですが、とりあえず本家のawscliを使ってみます。 さっきのAccess KeyとSecret Keyを使って aws configure で設定をして適当なバケットを作ってみましょう。 [utubo@tutsunom ~]$ aws configure AWS Access Key ID [None]: 8C072B46WQA5945CB6K9 AWS Secret Access Key [None]: nCt4TNicHXHkkq0uNqpbsMWX6UKCjHfsvPVNYEWX Default region name [None]: Default output format [None]: json [utubo@tutsunom ~]$ aws --endpoint-url http://172.20.10.2:8000 s3 mb s3://combat make_bucket: combat [utubo@tutsunom ~]$ aws --endpoint-url http://172.20.10.2:8000 s3 ls 2019-05-11 09:56:23 combat オッケーオッケー。そしたら適当なフォルダをsyncでアップロードします。 [utubo@tutsunom ~]$ ll -p testfiles/ total 240 -rw-r--r-- 1 utubo utubo 3123 Jul 15 2018 INSTALL -rw-r--r-- 1 utubo utubo 15220 Jul 15 2018 LICENSE -rw-r--r-- 1 utubo utubo 55 Jul 15 2018 MANIFEST.in -rw-r--r-- 1 utubo utubo 15759 Jul 15 2018 NEWS -rw-r--r-- 1 utubo utubo 1802 Jul 15 2018 PKG-INFO -rw-r--r-- 1 utubo utubo 15194 Jul 15 2018 README.md drwxr-xr-x 2 utubo utubo 4096 Jul 15 2018 S3/ -rwxr-xr-x 1 utubo utubo 146943 Jul 15 2018 s3cmd -rw-r--r-- 1 utubo utubo 21151 Jul 15 2018 s3cmd.1 drwxr-xr-x 2 utubo utubo 110 Jul 15 2018 s3cmd.egg-info/ -rw-r--r-- 1 utubo utubo 67 Jul 15 2018 setup.cfg -rw-r--r-- 1 utubo utubo 3793 Jul 15 2018 setup.py [utubo@tutsunom ~]$ aws --endpoint-url http://172.20.10.2:8000 s3 sync testfiles/ s3://combat/testfiles upload: testfiles/S3/AccessLog.py to s3://combat/testfiles/S3/AccessLog.py upload: testfiles/S3/Crypto.py to s3://combat/testfiles/S3/Crypto.py upload: testfiles/INSTALL to s3://combat/testfiles/INSTALL upload: testfiles/S3/ACL.py to s3://combat/testfiles/S3/ACL.py upload: testfiles/S3/ConnMan.py to s3://combat/testfiles/S3/ConnMan.py upload: testfiles/S3/Custom_httplib27.py to s3://combat/testfiles/S3/Custom_httplib27.py upload: testfiles/S3/BidirMap.py to s3://combat/testfiles/S3/BidirMap.py upload: testfiles/S3/CloudFront.py to s3://combat/testfiles/S3/CloudFront.py upload: testfiles/S3/Config.py to s3://combat/testfiles/S3/Config.py upload: testfiles/README.md to s3://combat/testfiles/README.md upload: testfiles/S3/Custom_httplib3x.py to s3://combat/testfiles/S3/Custom_httplib3x.py upload: testfiles/S3/HashCache.py to s3://combat/testfiles/S3/HashCache.py upload: testfiles/S3/Exceptions.py to s3://combat/testfiles/S3/Exceptions.py upload: testfiles/LICENSE to s3://combat/testfiles/LICENSE upload: testfiles/S3/ExitCodes.py to s3://combat/testfiles/S3/ExitCodes.py upload: testfiles/S3/FileDict.py to s3://combat/testfiles/S3/FileDict.py upload: testfiles/S3/PkgInfo.py to s3://combat/testfiles/S3/PkgInfo.py upload: testfiles/S3/MultiPart.py to s3://combat/testfiles/S3/MultiPart.py upload: testfiles/S3/Progress.py to s3://combat/testfiles/S3/Progress.py upload: testfiles/S3/FileLists.py to s3://combat/testfiles/S3/FileLists.py upload: testfiles/S3/__init__.py to s3://combat/testfiles/S3/__init__.py upload: testfiles/S3/S3Uri.py to s3://combat/testfiles/S3/S3Uri.py upload: testfiles/s3cmd.1 to s3://combat/testfiles/s3cmd.1 upload: testfiles/S3/SortedDict.py to s3://combat/testfiles/S3/SortedDict.py upload: testfiles/S3/Utils.py to s3://combat/testfiles/S3/Utils.py upload: testfiles/s3cmd.egg-info/PKG-INFO to s3://combat/testfiles/s3cmd.egg-info/PKG-INFO upload: testfiles/s3cmd.egg-info/SOURCES.txt to s3://combat/testfiles/s3cmd.egg-info/SOURCES.txt upload: testfiles/s3cmd.egg-info/requires.txt to s3://combat/testfiles/s3cmd.egg-info/requires.txt upload: testfiles/S3/S3.py to s3://combat/testfiles/S3/S3.py upload: testfiles/s3cmd to s3://combat/testfiles/s3cmd upload: testfiles/s3cmd.egg-info/dependency_links.txt to s3://combat/testfiles/s3cmd.egg-info/dependency_links.txt upload: testfiles/s3cmd.egg-info/top_level.txt to s3://combat/testfiles/s3cmd.egg-info/top_level.txt upload: testfiles/setup.cfg to s3://combat/testfiles/setup.cfg upload: testfiles/MANIFEST.in to s3://combat/testfiles/MANIFEST.in upload: testfiles/NEWS to s3://combat/testfiles/NEWS upload: testfiles/PKG-INFO to s3://combat/testfiles/PKG-INFO upload: testfiles/setup.py to s3://combat/testfiles/setup.py [utubo@tutsunom ~]$ aws --endpoint-url http://172.20.10.2:8000 s3 ls s3://combat PRE testfiles/ [utubo@tutsunom ~]$ aws --endpoint-url http://172.20.10.2:8000 s3 ls s3://combat/testfiles/ PRE S3/ PRE s3cmd.egg-info/ 2019-05-11 10:02:24 3123 INSTALL 2019-05-11 10:02:25 15220 LICENSE 2019-05-11 10:02:25 55 MANIFEST.in 2019-05-11 10:02:25 15759 NEWS 2019-05-11 10:02:25 1802 PKG-INFO 2019-05-11 10:02:24 15194 README.md 2019-05-11 10:02:25 146943 s3cmd 2019-05-11 10:02:25 21151 s3cmd.1 2019-05-11 10:02:25 67 setup.cfg 2019-05-11 10:02:25 3793 setup.py 頼れるね！ ね？簡単だったでしょ？ こんな具合でS3的なオブジェクトストレージを作ることができます。これくらい簡単だったらいっちょやってみっかって気分になりません？そんな気分になった方は是非お気軽に試してみて下さいね！ あ、最後にCeph Nanoの注意点ですが、 Ceph Nanoは開発やデモで使う目的で簡易的に作られてるものなので、本番環境では使わないでください。 あと、Ceph NanoはRed Hatが製品としてリリースしているものではないので、サポートは受けられません。 というわけで、今回はここまで。