レッドハットの杉村です。Ansible のテクニカルサポートをしています。 Ansible Automation Platform は旧 Ansible Tower の時代から、OpenShift での動作をサポートしています。これまでも自宅で試してみようという記事をこれまでも何度か書いてきました。 rheb.hatenablog.com rheb.hatenablog.com OpenShift が SIngle Node OpenShift (SNO) でインストールできるようになったということで、CRC をインストールして使っていたものを置き換えて使うことにしてみます。このPCに SNO をインストールして、Ansible Automation Platform 2.1 (AAP 2.1) を Operator でインストールするのを今回の記事の目標にします。 Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz 12core 64GB RAM 1TB SSD ネットワークの準備 PC を USB メモリから起動してインストールしていくのですが、起動した後に Red Hat のサイトとやりとりしながらインストールを進めるので、DHCP で適切なIPアドレスが割り当てられてインターネット接続ができるという環境が必要です。DHCP サーバになっている自宅のルータを設定して、MAC アドレスについて IP アドレスを固定で割り当てるようにしました。 DNS についても、あらかじめ準備しておく必要があります。dnsmasq で設定しました。 まとめますと、PC につける IP アドレスやホスト名をこのようにしています。 IPアドレス: 192.168.0.6 (DHCPで割り当て) ホスト名: ocp49.sugimura.home DNS (dnsmasq) の sugimura.home ドメイン (下記) local=/sugimura.home/ domain=sugimura.home server=192.168.0.1 expand-hosts address=/ocp.sugimura.home/192.168.0.6 address=/apps.ocp.sugimura.home/192.168.0.6 最後に、普段使う端末から SSH でログインするための鍵ペアを作っておきます。普段使っているものがあればそのまま使えます。公開鍵を設定するので用意しておいてください。 Assisted Installer の画面にアクセスしてUSBを作る console.redhat.com Create New Cluster のボタンを押して、インストールする構成のための設定をまず作ります。 Assisted Installer を選びます。 Cluster name: ocp Base domain: sugimura.home OpenShift version: OpenShift 4.9.9 Install single node OpenShift (SNO) にチェック Edit pull secret にチェックして内容を別ファイルに保存 次の画面で Add hosts を押して公開鍵を設定します。この公開鍵をインストールすることで、後で SSH でアクセスできるようになります。 ISO イメージが作成されるので、ダウンロードします。 USB から起動 Web ブラウザの設定画面はそのままにしておいて別な作業をします。 ダウンロードした ISO イメージを USB メモリに入れて、PC に挿して起動します。ISO を書くのは何を使ってもいいですが、わたしはこれを愛用しています。 www.balena.io USB から起動するための設定は PC ごとに異なるので、あれこれ試してください。わたしの PC の場合だと、SSD に設定されている grub のプロンプトを出して exit で抜けると USB デバイスから起動するようになっていました。 画面で設定しつつ進める USB から起動してしばらく経つと、起動したことを認識してくれます。 ネットワークを設定して、次に進みます。 最後に全体の確認があります。 Install cluster のボタンを押すと実際のインストール作業が進みます。 しばらく経ったら終わります。kubeadmin ユーザのパスワードが生成されるので、メモっておいてください。Download kubeconfig のボタンも押して、保存しておきましょう。 途中で多くのファイルのダウンロードや再起動があるので、焦らずじっくり待つのがコツです。10〜15分くらいで終わりました。 Web コンソールにログイン 表示されている Web Console URL にアクセスして、kubeadmin ユーザでログインします。 無事ログインできました。 アップデート CRC とは違って SNO は機能制限がされていない OpenShift なので、アップデートもできます。4.9.9 から 4.9.13 にアップデートしてみました。この Web Console から実行して、1時間くらいで無事更新されました。 ストレージを作る インストール直後の状態では、ストレージ (Persistent Volume) がありません。SNO では hostPath として作ります。 access.redhat.com SSH でログインして、スクリプトを作って実行しました。50GB x 10 の PV を作るものです。 $ ssh -i ~/.ssh/id_ed25519 core@192.168.0.6 ... [core@ocp49 ~]$ cat storage.sh #!/bin/sh for i in $(seq -w 10) do sudo mkdir -p /var/lib/storage/pv$i sudo chmod -R 777 /var/lib/storage/pv$i sudo chcon -R -t container_file_t /var/lib/storage/pv$i cat << HOSTPATHPV > storagepv.yaml apiVersion: v1 kind: PersistentVolume metadata: name: pv$i spec: capacity: storage: 50Gi accessModes: - ReadWriteOnce - ReadWriteMany - ReadOnlyMany persistentVolumeReclaimPolicy: Recycle hostPath: path: /var/lib/storage/pv$i HOSTPATHPV oc create -f storagepv.yaml rm -f storagepv.yaml done [core@ocp49 ~]$ kubeadmin でログインしてからスクリプトを実行します。 [core@ocp49 ~]$ oc login https://api.ocp.sugimura.home:6443 --username=kubeadmin --insecure-skip-tls-verify=true Authentication required for https://api.ocp.sugimura.home:6443 (openshift) Username: kubeadmin Password: XXXXXXXXXXXXXXXXXX Login successful. You have access to 66 projects, the list has been suppressed. You can list all projects with 'oc projects' Using project "default". [core@ocp49 ~]$ [core@ocp49 ~]$ sh storage.sh persistentvolume/pv01 created persistentvolume/pv02 created persistentvolume/pv03 created persistentvolume/pv04 created persistentvolume/pv05 created persistentvolume/pv06 created persistentvolume/pv07 created persistentvolume/pv08 created persistentvolume/pv09 created persistentvolume/pv10 created [core@ocp49 ~]$ [core@ocp49 ~]$ oc get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pv01 50Gi RWO,ROX,RWX Recycle Available 17s pv02 50Gi RWO,ROX,RWX Recycle Available 17s pv03 50Gi RWO,ROX,RWX Recycle Available 17s pv04 50Gi RWO,ROX,RWX Recycle Available 17s pv05 50Gi RWO,ROX,RWX Recycle Available 17s pv06 50Gi RWO,ROX,RWX Recycle Available 17s pv07 50Gi RWO,ROX,RWX Recycle Available 17s pv08 50Gi RWO,ROX,RWX Recycle Available 17s pv09 50Gi RWO,ROX,RWX Recycle Available 17s pv10 50Gi RWO,ROX,RWX Recycle Available 17s [core@ocp49 ~]$ 作った PV は Web Console からも確認できます。あとは PVC の要求に応じて割り当ててくれます。 Ansible Automation Platform 2.1 をインストール ここからはもう一つのテーマとして、この SNO で AAP 2.1 を Operator でインストールしてみます。 Ansible Tower の時代では独自のインストーラを実行していましたが、AAP 2.1 になって Operator で簡単に入れられるようになりました。左のメニューから OperatorHub をクリックして検索すると、Ansible Automation Platform の Operator が見つかります。 クリックしていくとこの Operator をインストールできます。 Automation Controller の Create instance を押して、作ってみます。ここでは名前を aap21 としてみました。Create を押すだけで終わりです。細かい設定をすることもできます。 しばらく待つとインストールが終わって、Routes に URL が生えてきます。 この Location にある URL にアクセスすると、見慣れたログイン画面が出てきます。 admin ユーザのパスワードは Secret に作られます。 AAP 2.1 にログインできました。 インスタンスは Pod に対応して作られます。OpenShift 側で Deployment から scale up すると、2つに増えたりしますのでお試しください。 まとめ 長くなりましたが、SNO のインストールと、OpenShift のアプリケーションとしての Ansible Automation Platform 2.1 のインストールを紹介してみました。 PC 1台で OpenShift を試すことができますので、ぜひ遊んでみてください。 OpenShift と Ansible Automation Platform の評価ライセンスリクエストはこちらからご利用いただけます。60日間利用できます。 www.redhat.com www.redhat.com Happy Automation!

みなさん、こんにちは。 Red Hatでソリューションアーキテクトをしている小野です。 MEC(Multi-access Edge Computing)の最新の標準化動向を以下の記事にてまとめてみましたのでご紹介します。 qiita.com 5G SAの商用化もアナウンスされ、いよいよ5Gも本格化してきます。 5Gの本格化により、MEC(Multi-access Edge Computing)などの新たなインフラストラクチャへのシフトが加速していくと予想されます。 標準化された内容がそのまま商用製品へ実装されるという訳ではありませんが、将来サーバーインフラの方向性を考える上では有益かと思いますので、 5GやMECに興味があるけど、標準化のドキュメントを読みこむ時間がない方、中長期のインフラ戦略を検討されている方など、一助になれば幸いです！ ぜひご活用ください！ エッジ-クラウドの全体俯瞰

Recap: OpenShift Commons Gathering Japan 2021 (vol.1) 2021年12月に大盛況のうちに閉幕した 「 OpenShift Commons Gathering Japan 2021 」。 このイベントレポートとして、今回から3回に渡ってキーノートの内容を振り返っていきます。 OpenShift Commons Gathering Japan 2021 第一回目はレッドハットから見た「グローバルのコンテナ市場の実態」です。 アジア全体のビジネス開発を担当するRed Hat 岡下さんから、様々な点でグローバルの動向を語っていただきました。 さてさて。レッドハットがみるグローバル市場はどういった傾向があるのでしょうか!? ITリーダーの85%が回答「アプリケーション戦略の鍵はKubernetes」 グローバルのITリーダーの多くは、アプリケーションのデプロイ先としてKubernetesの重要性を認知し始めています。 ただしグローバルでは、早くアプリケーションをデプロイしたい！という選択だけではなく、 正しくデプロイできる安心感 を求めてKubernetes環境が選ばれてきている傾向があります。 エンタープライズ向けオープンソースの現状：Red Hat レポート 85%が、クラウドネイティブアプリケーション戦略の鍵はKubernetesであると同意 OpenShiftをはじめ、Kubernetes環境はアプリケーションをオーケストレーションする機能を有しています。だからこそ、従来型のシステムマネージメントに頼るのではなく、どこまでKubernetes環境に アプリケーションの運用 を任せていけるかがポイントです。アプリケーション運用の自動化に委ねている企業ほど、Kubernetesを上手く使いこなせている傾向がありますね。 顧客サービスに近い「金融業界」が一歩先へ 次にグローバルではどういった業界が一歩先を進んでいるのでしょうか!? OpenShiftの導入事例をみると、顧客サービスに近い業界で利用されていることが多く「金融業界」が一歩先を進んでいます。 エンタープライズ向けオープンソースの現状：Red Hat レポート コンテナの導入状況は業界によって異なる また、過去の事例でいうと、 ドイツ銀行 や マッコーリ銀行 は、 アプリケーションのデプロイ運用に人手をかけず に顧客へ新しいサービスを迅速に提供し続けています。 www.youtube.com インフラ運用が足かせにならないように、早くサービスをデプロイできる環境をKubernetesで作っていきたいですね。 このあと日本IBM様より、日本市場における金融事例とコンテナの適用成熟度モデルを紹介していただいています。 IBMのOpenShift活用戦略（日本アイ・ビー・エム 佐藤 卓由 氏） - YouTube まとめ グローバルにおいてコンテナ導入をリードする企業は、コンテナのデプロイメントを始めとする アプリケーションの運用 をKubernetesの自動化機能に委ねています。 これを体現することによって、サービス提供のアジリティ向上や安定性の維持といったビジネス価値へとつなげているようですね。 次回は日本のコンテナビジネスのイマに迫ります!! お楽しみにっ。 オンデマンド配信中!! OpenShift Commons Gathering Japan 2021は以下の特設サイトにて、ログイン無しで動画、資料の無償配信をおこなっています。 www.redhat.com 今回ご紹介したキーノートセッションも是非お楽しみください!! www.youtube.com 本ブログは Solution Architect 北山 よりお送りしました。

レッドハットのソリューションアーキテクトの森です。 皆様2022年もよろしくお願い致します。 Red Hatのミドルウェアの中には、ビジネスにおける最適化問題を解決するソリューションとして、Business Optimizerというものがあることをご存知でしょうか？ Business Optimizer について Red Hat Business Optimizer はプランニング問題を解決するAI制約ソルバーです。限られたリソース内で、様々で複雑な制約条件を満たしつつ、最良の結果を得たいというようなケースにおいて、どの組合せが最適なのかを現実的な時間で探索することができます。オペレーションズリサーチの専門的な知識や難解な数式等は不要で、Javaプログラミングとルールの記述でこれらを実現できることが特長です。 オープンソースソフトウェア（OSS）コミュニティの OptaPlanner をベースとしており、Red Hat社により製品化をされて、ルールエンジン「 Red Hat Decision Manager 」 の機能の一つとして提供をされています。 昨年、コミュニティ版のOptaPlanner 8がリリースをされて、付属のサンプルも一新されました。 今回は、OptaPlanner 8の新しくなったサンプルを紹介したいと思います。 Let's Try!! JDK11以降を事前にインストールしておいてください。 プロジェクトをローカルにダウンロードしてから実行 プロジェクトは こちら になります。 適当なフォルダにて、下記のコマンドを実行してください。 $ git clone https://github.com/kiegroup/optaplanner-quickstarts.git $ cd optaplanner-quickstarts $ ./runQuickstartsFromSource.sh もしくは、こちらの リンク からzipファイル（400MBくらいあります）をダウンロードして、適当なフォルダに解凍し、中の runQuickstarts.sh ファイルを実行してください。（Windowsの場合は、 runQuickstarts.bat ファイルを実行） ターミナルから実行した場合、以下のようなログが表示されれば、起動完了です。 __ ____ __ _____ ___ __ ____ ______ --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \ --\___\_\____/_/ |_/_/|_/_/|_|\____/___/ 2022-01-04 16:20:48,499 INFO [io.quarkus] (Quarkus Main Thread) optaplanner-quickstarts-showcase 8.14.0.Final on JVM (powered by Quarkus 2.5.0.Final) started in 3.187s. Listening on: http://localhost:8080 2022-01-04 16:20:48,513 INFO [io.quarkus] (Quarkus Main Thread) Profile dev activated. Live Coding activated. 2022-01-04 16:20:48,515 INFO [io.quarkus] (Quarkus Main Thread) Installed features: [cdi, resteasy, resteasy-jackson, smallrye-context-propagation, vertx, webjars-locator] ブラウザで、 http://localhost:8080/ にアクセスをしてください。 サンプルのメニュー画面が表示されると思います。 School timetabling (授業のスケジューリング) Facility location problem (施設配置問題) Maintenance scheduling (保守工事のスケジューリング) Call center (コールセンターの処理時間最適化) Vehicle routing (配送経路問題) Vaccination scheduling (ワクチン接種スケジュール最適化) Order picking (物流倉庫からのピッキング作業最適化) 今回はこの中から、Order pickingについて、解説をしていきたいと思います。 Order picking を動かしてみる ピッキングとは物流用語で、指定された商品を保管されている倉庫の場所から取り出す作業のことを指しますが、 「オーダーピッキング」とは、注文単位（1オーダーずつ）にピッキング作業を行う方法です。 他の方法としては、複数の注文に含まれる商品をまとめてピッキングする「総量ピッキング」という方法もあります。 オーダーピッキングは通販系の倉庫で導入されているケースが多く、商品数や発注頻度が高い注文に対して、迅速で柔軟に対応できるという点や、 仕分けスペースが不要で、ピッキング後すぐに梱包作業に入れるというメリットがあります。 一方で、オーダーごとにピッキングをするため、商品を探す手間がかかったり、倉庫内の移動効率が悪くなったりすることがデメリットとしてあげられます。 本サンプルでは、仮想の物流倉庫に対して、倉庫内の移動距離を最小にしつつ、オーダーに必要な商品を集めるための計画を立てるものになっています。 では、早速サンプルを立ち上げてみましょう。 ▷Launch -> Show をクリックすると、ブラウザの別画面でアプリが起動します。 ▷Solve をクリックすると、最適化が始まりますが、その前に問題の初期データについて確認をしていきましょう。 右上の Map をクリックしてみてください。 縦3行 * 横5列 の枠が表示されていますが、これは倉庫の棚を表しています。 棚のサイズは縦10m * 横2mで、棚と棚の間隔は3mとなっています。 一応、棚のごとに商品のカテゴリーが決まっているようで、以下のようになっています。 C1, C2 列は、特に定義はされていないようです。 自分でカスタマイズしてみる際には、変更を加えてみてください。 倉庫の棚と商品の定義は、以下のソースファイルの中に記述されています。下記にその一例を示します。 ./optaplanner-quickstarts/use-cases/order-picking/src/main/java/org/acme/orderpicking/bootstrap/ProductDB.java ... SHELVINGS_PER_FAMILY.put(ProductDB.ProductFamily.FRUITS_AND_VEGETABLES, Arrays.asList( newShelvingId(COL_A, ROW_1), newShelvingId(COL_A, ROW_2))); ... ... PRODUCTS.add(new ProductDBRecord(new Product(nextId(), "Iceberg Lettuce Each", 2500, null), ProductFamily.FRUITS_AND_VEGETABLES)); PRODUCTS.add(new ProductDBRecord(new Product(nextId(), "Carrots 1Kg", 1000, null), ProductFamily.FRUITS_AND_VEGETABLES)); PRODUCTS.add(new ProductDBRecord(new Product(nextId(), "Organic Fair Trade Bananas 5 Pack", 1800, null), ProductFamily.FRUITS_AND_VEGETABLES)); PRODUCTS.add(new ProductDBRecord(new Product(nextId(), "Gala Apple Minimum 5 Pack", 25 * 20 * 10, null), ProductFamily.FRUITS_AND_VEGETABLES)); PRODUCTS.add(new ProductDBRecord(new Product(nextId(), "Orange Bag 3kg", 29 * 20 * 15, null), ProductFamily.FRUITS_AND_VEGETABLES)); ... 次に、右上の Unassigned をクリックしてみてください。 商品をピッキングするトロリーと、オーダーの情報があります。 初期条件では、トロリーは5台与えられています。それぞれのトロリーに4個のバケットがあり、バケット1つの容量は48000です。 またオーダーは、8つ与えられています。 Order_1 のタブをクリックすると、オーダー1に必要な商品の内容が確認できます。 必要な商品の位置は、 Warehouse Location に、 商品棚、棚の左右、棚内の列位置 の形式で書かれています。 例えば、下記のオーダー1の2番目の商品のバターであれば、 (A,3)の棚、左側の上から6番目 の位置にある、ということになります。 トロリーの台数や、バケットの数とその容量、オーダーの数は、以下のソースファイルで設定をしています。 ./optaplanner-quickstarts/use-cases/order-picking/src/main/java/org/acme/orderpicking/rest/OrderPickingSolverResource.java ... /** * Number of trolleys for the simulation. */ private static final int TROLLEYS_COUNT = 5; /** * Number of buckets on each trolley. */ private static final int BUCKET_COUNT = 4; /** * Buckets capacity. */ private static final int BUCKET_CAPACITY = 60 * 40 * 20; /** * Number of orders for the simulation. */ private static final int ORDERS_COUNT = 8; ... またオーダーの内容については、 ProductDB.java に設定された商品データを元に、自動で生成されるようになっています。 そちらの詳細について興味のある方は、以下のソースを確認してみてください。 ./optaplanner-quickstarts/use-cases/order-picking/src/main/java/org/acme/orderpicking/bootstrap/DemoDataGenerator.java では、与えられたオーダーの商品をピッキングするための、トロリー移動経路の最適化を実行してみたいと思います。 最適化を実現するための制約条件は以下のようになっています。 制約条件の重要度により、レベル分けをすることが可能です。 Hard制約（満たされない場合は計画が破綻するもの） 全てのオーダーの商品が選択されていること 異なるオーダーの商品が、同じバケットに混在してはいけない バケットの容量を超えて、商品を入れることはできない 満たされない場合は Hard制約のスコアを-1 Soft制約（できれば順守したい制約） トロリーが移動する距離を最小限にする Soft制約のスコアから移動距離分をマイナス(縦5m、横3mの移動の場合は-8) 注文を異なるトロリーに分割してピッキングすることは避ける 各トロリーに割り付けられたオーダーの数の分、 Soft制約のスコアを-1000 とする 制約条件については、以下のソースファイルに記述がされております。 参考に 注文を異なるトロリーに分割してピッキングすることは避ける の実装の例を示します。 ./optaplanner-quickstarts/use-cases/order-picking/src/main/java/org/acme/orderpicking/solver/OrderPickingConstraintProvider.java ... /** * An Order should ideally be prepared on the same trolley, penalize the order splitting into different trolleys. */ Constraint minimizeOrderSplitByTrolley(ConstraintFactory constraintFactory) { return constraintFactory.forEach(TrolleyStep.class) .groupBy(trolleyStep -> trolleyStep.getOrderItem().getOrder(), countDistinctLong(TrolleyStep::getTrolley)) .penalizeLong("Minimize order split by trolley", HardSoftLongScore.ONE_SOFT, (order, trolleySpreadCount) -> trolleySpreadCount * 1000); } ... 上記の制約を考慮した上で、どのトロリーがどのオーダーのピッキングをするのか、各トロリーはどのような順序で各棚の商品まで移動するのか、与えられた時間内で最良のスコアとなるように組み合わせを入れ替えます。 それでは、左上の緑の ▷Solve をクリックしてみましょう。 各トロリーに、どの注文の商品をどのような順番で取りに行くか、リストが表示されます。 また時間の経過とともにリストの内容が更新されていき、それに伴い上部にあるスコアも変化している様子が見えると思います。 例えば上記の状態では、5台あるトロリーのうち、4台が稼働予定となっています。 各トロリーの移動距離はそれぞれ、 168m , 132m , 178m , 160m となっており、合計 638m のため、Soft制約のスコアに -638 を与えます。 また、トロリー1は、3つのオーダーの商品をピッキングしているので、Soft制約のスコア 3✖️-1000=-3000 を与えます。 各トロリーの割り付けオーダーは合計では9となるため、Soft制約のスコアに -9000 を与え、移動距離分のスコアと合わせて、 -9638 となっています。 次に、右上の Map をクリックしてみると、各トロリーの移動経路が倉庫マップ上に表示されていると思います。 終わりに いかがでしたでしょうか？ 今回は、すぐに触って頂けるサンプルの中から、Order Picking についてご紹介を致しました。 Red Hat Business Optimizer は、企業のビジネスの重要な意思決定である計画策定業務を標準化し、いつ・どこで・誰がやっても高品質な計画を作成を可能にします。 また人手作業では困難だった計画の柔軟な変更や、複雑な制約条件の見直しにも迅速に対応し、より効率的な計画策定業務を実現します。 最適化のツールに興味がある・もう少し詳しい内容が聞きたい、などありましたら、是非弊社までお問合せ頂ければと思います。

OpenStackやOpenShiftなどのCloud製品を担当しているソリューションアーキテクトの輿水です。 今回はOpenShift Container Platformのライフサイクル変更についてのお話です。10月にOpenShift Container Platform 4.9がリリースされたタイミングで、OpenShift 4のサポート期間が変更され、4.7以降のすべてのリリースのサポート期間が18ヶ月になりました。 変更前 フルサポート約4ヶ月＋メンテナンスサポート約5ヶ月＝合計約9ヶ月間のサポート Extended Update Support （EUS）リリースのみ18ヶ月間のサポート 該当するEUSリリースは4.6のみ EUSを利用するためにはプレミアムサポートサブスクリプションが必要 変更後 すべてのリリースでサポート期間は18ヶ月 フルサポート期間：6ヶ月または次期リリース一般提供日＋90日のいずれか長い方 メンテナンスサポート期間：フルサポート終了日から18ヶ月まで 偶数リリース（4.8, 4.10, 4.12）がExtended Update Support （EUS）リリース EUSはスタンダードサポートサブスクリプションとプレミアムサポートサブスクリプション両方で利用可能 EUSリリースから次のEUSリリースへのテスト済アップグレードパスが提供される ライフサイクル変更の理由について、Red Hat が公開している英語版ブログ「 Hybrid cloud blog 」に「 Time Is On Your Side: A Change to the OpenShift 4 Lifecycle 」という記事があります。この英語版ブログ「 Hybrid cloud blog 」は頻繁に更新されていて技術的なこともたくさん紹介されているのですが、英語のみなのであまり日本のユーザーの目に触れることはないように感じます。良い記事があったらなるべくご紹介したいとは思います。 今回は「 Time Is On Your Side: A Change to the OpenShift 4 Lifecycle 」の内容を意訳してかいつまんでご紹介します。 すべてのリリースが18か月にもかかわらず、なぜEUSの概念を維持するのか？ Red Hatは、2つの主な理由から、EUSリリースの概念を維持することを決定しました。 ひとつめは、今後の変化に備えることです。今後数年間でUpstreamのKubernetesが進化し、18か月以上を安全に提供できるようになることを期待しています。18か月よりサポートが伸びる場合は、特定のリリースで対応します。偶数リリース（4.6、4.8、4.10、4.12 ..）をEUSリリースとして宣言しますが、18か月以上のサポートを提供できるようになった場合は、その先の偶数リリースで対応します。 ふたつめはアップグレードに関係しています。アップグレード時にKubernetesのバージョンをスキップすることはできません（例えばKubernetes1.22からKubernetes1.24へのアップグレードは不可）。アップグレードはひとつずつ順次実行する必要があります。 Red Hatは、OpenShift 4.8以降の偶数リリース間、たとえば、4.8から4.10または4.10から4.12といったアップグレードに関して、テスト済の認定されたアップグレードパスを提供します。アップグレードの開始時に、ワーカーノードでのアップグレードプロセスを一時停止し、2つのバージョンのOpenShiftを実行（コントロールプレーンアップグレードを2度実行）してから、一時停止を解除できるようにしています。コントロールプレーンはシリアルにアップグレードしますが、アップグレード中のワーカーノードの再起動が1回少なくなります。 テストマトリックスのサイズをRed HatとlISVベンダーの両方にとって管理しやすい状態に保つために、この合理化されたワーカーアップグレードプロセスは、EUSリリースにのみ対応します。 スタンダードサポートサブスクリプションとプレミアムサポートサブスクリプション両方でEUS利用可能にした理由 多くの場合、ビジネス上の理由（本番環境）でひとつのプレミアムサポートサブスクリプションを購入し、他のユースケース（開発やテスト環境）ではスタンダードサポートサブスクリプションを購入します。サブスクリプションでライフサイクルが異なるという事は、クラスターのライフサイクルの状況によっては、テスト環境でのテストが本番環境と一致しない事が考えられます。そのような状況を回避するために、スタンダードサポートサブスクリプションとプレミアムサポートサブスクリプション両方で利用可能にしました。 バージョンの選択 4.6リリースがサポート期間の長いEUSであると発表されてから、4.7や4.8,4.9がユーザーのユースケースに適した機能を持っていていたとしても、サポート期間の長い4.6を選択する傾向があるとわかりました。本来ユーザーは、必要な機能に基づいてバージョンを選択する自由があります。すべてのリリースに一貫した長期サポートを提供することで、ユーザーが利用したいバージョンを選択できると考えます。 ユーティリティ 多くのお客様は、OpenShiftの新バージョンのロールアウトのために、開発環境・テスト環境・商用環境を持っています。場合によっては、様々なベンダーが関与しており、他のベンダーに環境を引き渡す前に、ソフトウェアを使用する時間を確保する必要があります。彼らのCI/CDプロセスは平均して四半期で、四半期中のどのタイミングで新しいリリースが提供されるかによって、プラスマイナス2ヶ月になる可能性があり、最も安全または最も保守的な確保時間の見積もりは6ヶ月です。ローリングウィンドウ方式が平均12ヶ月で製品を生産している場合、リリースから6ヶ月（12ヶ月-6ヶ月=6ヶ月）のユーティリティしか得られませんでした。Red Hatは、確実に12ヶ月のユーティリティを提供する方法を考えて、18ヶ月のライフサイクルによって問題が解決できると考えます。 APIがサポートの長さを決定する OpenShiftをサポートする期間を決定するために、KubernetesとCNCFオープンソースソフトウェアプロジェクトを調べました。ライフサイクル期間を分析する場合、ベンダーが考慮しなければならない最も重要な要素は、お客様が可能な限り特定のリリースの利用を継続した場合に何が起こるかです。たとえば、OpenShift（Kubernetes）のリリースを18か月間継続するとどうなるか？現在使用しているリリースのAPIとアップグレード先のリリースのAPI間で、アップグレードを通過できるのか？といったことです。 Kubernetes Upstreamは最大で12か月のサポートと宣言しています。 OpenShiftでサポートされているものとして公開しているAPIを考えると、お客様に安全にサポートを拡張できる最長の期間は18か月であると判断しました。 Kubernetesが現在の1.2Xから成熟するにつれて、1.3X KubernetesバージョンからOpenShiftを構築するときに、このサポート範囲を拡張できる可能性はあります。 パッチのリリース頻度 すべてのマイナーリリース（OpenShift 4.y）を18か月サポートするということは、Red Hatはいつでも6リリース（開発中の現在のリリースを数える）のコードブランチを維持することを意味します。 OpenShift 3の場合、より迅速なリリースを必要とする重大なバグとセキュリティの問題を除いて、約1か月に1回パッチをリリースしていました。OpenShift 4にでは週に1回パッチをリリースし、お客様がコードの継続的デリバリーに近い何かを体験できるようにしました。 お客様向けに6つのバージョンのOpenShiftをサポートすることを検討しているため、OpenShift3とOpenShift4の経験をブレンドすることにしました。開発ブランチ（ナイトリーと呼ばれることもあります）では、現在のGAバージョンと、現在より1つ古いリリースに対して週に1回の頻度でパッチをリリースし続けます。3番目、4番目、および5番目に古いリリースでは、月に1回の頻度でパッチをリリースします。より早くリリースする必要がある例外もありますが、この頻度が、現在のリリースに基づく平均値になります。 OpenShiftリリース頻度 結論として、メジャーナンバー（OpenShift 4）のリリース中にライフサイクルを頻繁に変更することはありません。今回のライフサイクルの変更によって、Kubernetes Upstreamに 遅れをとるようなことはありません。何年にもわたって行ってきたように、Upstreamから1クォーター（四半期）後にリリースし続けます。 2022年にKubernetes Upstreamは年間4回のリリースから年間3回のリリースに移行します。これは、OpenShiftが2022年にOpenShift 4の3つのマイナーバージョンをリリースすることを意味します。 ブログの締めくくりには「このブログに含まれている背景情報によって、何が変わったのかだけでなく、なぜ変わったのかをよりよく理解できることを願っています。」と書かれておりましたが、いかがでしたでしょうか？ OpenShift 4のリリースサイクルは今後しばらくは変わらない OpenShift 4のマイナーバージョンは年3回のリリース パッチに関する記載の部分の図を見るとOCP 4.16 / Kube 1.29くらいまでは予定にある ライフサイクルとリリースサイクルによれば、来春には4.10がリリースされてEUStoEUSのアップデートに関するお話ができるのではと思っております。

みなさんハッピークリスマス。Red Hatのさいとうです。 AnsibleユーザグループのAdvent Calender 2022最終日の記事として、2022年のAnsibleにどのような変化がありそうなのかといったあたりの個人的な予想を書き残しておこうと思います。 この記事は、AnsibleユーザコミュニティのAdvent Calendarですから、アップストリームの情報を元にして書いています。Red Hatのテクニカルサポートには問い合わせないでね! 2021年のAnsibleのふりかえりについては、 コチラ をどうぞ。 2022年にやってきそうな変化 現在のAnsible Core 2.xは、ある程度安定期に入っているため、機能面で劇的な変更が加えられることはしばらくないものと考えています。しかし、Ansible Coreが稼動するPlaybookの実行環境としては、2022年に大きな変化がやってきそうです。 現在、多くのAnsible Playbookの実行環境は、コントローラとなるノードのシステムワイドや、ユーザのホームディレクトリ、そしてPythonのvirtualenvを利用した仮想的な実行環境を利用して構築されています。 Ansibleのモジュール群は、Windows向けのモジュールを除いて、Pythonで書かれた小さなプログラムで構成されています。モジュールを書くうえで必要となる、ファイルのパーミッションチェックなどな基本的な機能は、Ansibleのコアにライブラリとしてバンドルされているため、特に意識することなくモジュールから利用できます。 しかし、例えばEC2インスタンスの作成といったオペレーションに利用するbotoなどのライブラリについては、利用者がモジュール毎に個別にコントロールノードの実行環境に準備する必要があります。Ansibleのコア機能に含まれない、モジュールが動作するためにのみ必要なライブラリ群のインストールやバージョンを意識して、実行環境を維持管理する必要がありました。この管理を常に意識していないと、あるコントロールノードの実行環境で動作したPlaybookが、別のコントロールノードではライブラリ不足やバージョンミスマッチで動作しない...といった問題が発生することになります。 この維持管理に関するコストは、Playbookによって自動化したいオペレーションが多様化すればするほど顕著に大きくなってきます。また、PlaybookをRole化して再利用が進むと、それらが想定外の環境で起動される可能性もでてきます。 このような、実行環境の差異を解決するために、これまでいくつかのアプローチが存在していました。 実行環境を構築するための手順書による手動構築する 1.の構築自体を自動化するためのブートストラップ的なPlaybookの作成と実行する 実行環境をPythonのvirtualenvで作成後にrpmなどでパッケージ化し、コントロールノードにインストールして利用する 水平展開しやすいのは、疑いなく3.ですが、パッケージの適用後にコントロールノードの管理者権限を持つ利用者によって改変されてしまう可能性は残ります。 そこで、3.のパッケージ化のアプローチをもう一歩進めてコンテナ化してしまえば良いのではないか...というアイデアが数年前から議論されていました。 以降では、2022年に向けて広く普及しそうな予感がしている、このコンテナベースのPlaybook実行環境についてご紹介します。 コンテナベースの実行環境 コンテナベースの実行環境は、その名の通り、Ansible CoreやCollections、それらが必要とするPythonモジュールなどのライブラリ群をコンテナとしてパッケージ化したものです。 コンテナ化された実行環境では、単純にpodmanやdockerでansible-playbookコマンドを実行するだけでなく、Playbookの実行ログを残したり、SSH接続に利用する鍵が配置されたントロールノードのディレクトリを透過マウントして利用できるようにするなど、これまでの実行環境では意識する必要のなかった点も考慮しなければなりません。 Ansibleプロジェクトでは、このようなコンテナ環境固有の設定を開発者や利用者がそれほど意識せずに、本来やりたいことに集中できるよう、コンテナベースの実行環境を「使う」、そして「作る」ためのツールを提供しています。 それぞれのツールの細い使い方は、来年のどこかでご紹介するとして、ここではソースコートリポジトリやドキュメンのリンク、簡単な動作サンプルをご紹介しようと思います。 使う 残念ながら、ansible-playbookコマンドには、コンテナベースの実行環境を利用してPlaybookを実行する機能はありません。 その役割の担うのが Ansible Navigator です。Ansible Navigatorは、コンソールベースのPlaybookランチャーです。 バックエンドとして Ansible Runner を利用しており、従来のコントローラ上にインストールされたAnsible Coreや、コンテナベースの実行環境を利用してPlaybookを実行できます。 ディレクトリ構造 ├── ansible-navigator.yml ...(1) ├── inventory │ └── hosts ...(2) ├── logs └── playbook └── test.yml ...(3) (1) 設定ファイル - ansible-navigator.yml 参考情報 --- ansible-navigator: execution-environment: container-engine: docker enabled: True image: quay.io/ansible/ansible-runner:stable-2.12-devel pull-policy: missing logging: level: debug append: True file: ./logs/ansible-navigator.log mode: stdout playbook-artifact: enable: True replay: ./logs/artifact/replay.json save-as: ./logs/artifact/replay.json (2) インベントリファイル - inventory/hosts [linux] 192.168.125.110 192.168.125.111 192.168.125.112 [linux:vars] ansible_user=ansible (3) Playbook - playbook/test.yml --- - hosts: all gather_facts: false tasks: - ping: それでは、テスト用のPlaybookを実行してみましょう。今回の実行例では、 ansible-navigator run コマンドを実行すると、ansible-navigator.ymlファイルの environmentl.image パラメータに指定したコンテナイメージをダウンロードし、そのコンテナ内でPlaybookを実行します。このようにして、Ansible Navigatorとコンテナベースの実行環境を利用すれば、開発環境、テスト環境、そして本番環境で完全に統一された実況環境を利用することができます。 Playbookの実行ログは、(1)の ansible-navigator.logging.file にしたがって、 logs/ansible-navigator.log に記録されます。また、SSH接続に必要となるコントロールノード上の秘密鍵や、ssh-agentよってストアしている秘密鍵のパスフレーズも、ansible-navigatorによって透過的に参照する形でコンテナ実行環境が起動されます。 $ pip install --user ansible-navigator $ eval `ssh-agent` $ ssh-add Enter passphrase for /home/hsaito/.ssh/id_rsa: ******** Identity added: /home/hsaito/.ssh/id_ecdsa (/home/hsaito/.ssh/id_ecdsa) $ ansible-navigator run playbook/test.yml -i inventory/hosts ----------------------------------------------------------------------------------- Execution environment image and pull policy overview ----------------------------------------------------------------------------------- Execution environment image name: quay.io/ansible/ansible-runner:stable-2.12-devel Execution environment image tag: stable-2.12-devel Execution environment pull policy: missing Execution environment pull needed: True ----------------------------------------------------------------------------------- Updating the execution environment ----------------------------------------------------------------------------------- stable-2.12-devel: Pulling from ansible/ansible-runner a1d0c7532777: Pull complete 0051e33d76d8: Pull complete 3fb241a85b00: Pull complete 014e39b4ae38: Pull complete 442efd345444: Pull complete 79831b585400: Pull complete 27b3a0cd32c9: Pull complete a0432b3d84b6: Pull complete 93e0336932fc: Pull complete 44e3598950f0: Pull complete fc120b105d20: Pull complete 25df1b0a7e8d: Pull complete b1cb03d0f630: Pull complete 324f5147ca8f: Pull complete Digest: sha256:2c44521150e5f260a85ee99fee4f3a5e41216510c9f408d6e2a64df9eb9064ab Status: Downloaded newer image for quay.io/ansible/ansible-runner:stable-2.12-devel quay.io/ansible/ansible-runner:stable-2.12-devel PLAY [all] ********************************************************************* TASK [ping] ******************************************************************** ok: [192.168.125.110] ok: [192.168.125.112] ok: [192.168.125.111] PLAY RECAP ********************************************************************* 192.168.125.110 : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 192.168.125.111 : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 192.168.125.112 : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 一方で、従来のコントローラに直接インストールされたPlaybook実行環境を利用し続けたい場合もあるでしょう。ansible-navigatorコマンドに --ee false オプションを指定することで、コンテナベースの実行環境ではなく、従来のコントローラ上にインストールされたansible-playbookコマンドを利用することもできます。 $ ansible-navigator run --ee false playbook/test.yml -i inventory/hosts PLAY [all] ********************************************************************* TASK [ping] ******************************************************************** ok: [192.168.125.111] ok: [192.168.125.112] ok: [192.168.125.110] PLAY RECAP ********************************************************************* 192.168.125.110 : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 192.168.125.111 : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 192.168.125.112 : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 このように、ansible-navigatorを利用すれば、Playbook実行時に、従来のコントロールノード上にインストールされた実行環境と、コンテナベースの実行環境を必要に応じて選択することができます。 作る コンテナベースの実行環境で利用するコンテナイメージは、基本的には Quay.io から提供されるansible-runnnerのイメージを利用します。 これをカスタマイズして独自のCollectionsやPythonモジュールをインストールした状態で利用したいというユースケースも当然発生してくるでしょう。 Ansible Builder を利用すれば、利用者がカスタマイズしたコンテナイメージを作成することができます。 公式ドキュメント と元にして、以下のようなティレクトリを構成してカスタムコンテナイメードを作成する例をご紹介します。 ディレクトリ構造 . ├── ansible.cfg ...(1) ├── bindep.txt ...(2) ├── custom_ee.yml ...(3) ├── requirements.txt ...(4) └── requirements.yml ...(5) (1) Ansible Core設定ファイル - ansible.cfg [defaults] host_key_checking=false (2) コンテナイメージ作成時にインストールするOSパッケージ群 - bindep.txt krb5-devel [platform:rpm] (3) Ansible Builderのコンテナビルド設定ファイル - custom_ee.yml version: 1 build_arg_defaults: ANSIBLE_GALAXY_CLI_COLLECTION_OPTS: '-v' EE_BASE_IMAGE: 'quay.io/ansible/ansible-runner:stable-2.11-devel' ansible_config: 'ansible.cfg' dependencies: galaxy: requirements.yml python: requirements.txt system: bindep.txt additional_build_steps: prepend: | RUN whoami RUN cat /etc/os-release append: - RUN echo This is a post-install command! - RUN ls -la /etc (4) コンテナイメージ作成時にインストールするPythonモジュール群 - requirements.txt awxkit (5) コンテナイメージ作成時にインストールするCollections/Roles群 - requirements.yml 参考情報 collections: - ansible.posix - awx.awx - community.general それでは、Ansible Builderを利用してカスタマイズされたコンテナ実行環境のイメージを作成してみます。以下の例では、 -f オプションに(3)のビルド設定ファイル、 -t オプションで、作成するコンテナイメージに付与するタグ名を指定してビルドしています。 $ pip install --user ansible-builder $ ansible-builder build -f custom_ee.yml -t custom_ee:2.11 Running command: docker build -f context/Dockerfile -t custom_ee:2.11 context Complete! The build context can be found at: /home/hsaito/work/testing/ansible-builder/custom_ee/context $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE custom_ee 2.11 3c5ad277f944 19 seconds ago 780MB 作成したイメージは、Ansible Navigatorから利用できます。先程「使う」で利用したAnsible Navigatorのディレクトリで、実際にカスタムイメージを利用してPlaybookを実行してみましょう。(3)ではベースイメージ( build_arg_defaults.EE_BASE_IMAGE )として、Ansible Core 2.11を指定しています。 今回は、 --eei オプションで、カスタムイメージのタグを指定しています。また、Ansible Coreのバージョンが2.11であることを確認するために -vv オプションもあわせて指定しています。 $ ansible-navigator run --eei custom_ee:2.11 playbook/test.yml -i inventory/hosts -vv ansible-playbook [core 2.11.7.post0] config file = None configured module search path = ['/home/runner/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules'] ansible python module location = /usr/local/lib/python3.8/site-packages/ansible ansible collection location = /home/runner/.ansible/collections:/usr/share/ansible/collections executable location = /usr/local/bin/ansible-playbook python version = 3.8.8 (default, Aug 25 2021, 16:13:02) [GCC 8.5.0 20210514 (Red Hat 8.5.0-3)] jinja version = 2.10.3 libyaml = True No config file found; using defaults Skipping callback 'awx_display', as we already have a stdout callback. Skipping callback 'default', as we already have a stdout callback. Skipping callback 'minimal', as we already have a stdout callback. Skipping callback 'oneline', as we already have a stdout callback. PLAYBOOK: test.yml ************************************************************* 1 plays in /home/hsaito/work/testing/ansible-navigator/playbook/test.yml PLAY [all] ********************************************************************* META: ran handlers TASK [ping] ******************************************************************** task path: /home/hsaito/work/testing/ansible-navigator/playbook/test.yml:6 ok: [192.168.125.110] => {"ansible_facts": {"discovered_interpreter_python": "/usr/libexec/platform-python"}, "changed": false, "ping": "pong"} ok: [192.168.125.112] => {"ansible_facts": {"discovered_interpreter_python": "/usr/libexec/platform-python"}, "changed": false, "ping": "pong"} ok: [192.168.125.111] => {"ansible_facts": {"discovered_interpreter_python": "/usr/libexec/platform-python"}, "changed": false, "ping": "pong"} META: ran handlers META: ran handlers PLAY RECAP ********************************************************************* 192.168.125.110 : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 192.168.125.111 : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 192.168.125.112 : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 まとめ Ansible Navigatorは、Ansibleプロジェクトの中でも、2021年に立ち上げられた最も若いプロジェクトです。まだまだプロダクション環境での運用には耐えない部分もありますが、2022年も安定性の向上や機能拡張が進められていくことでしょう。 今回ご紹介したのはCLIでの利用例でしたが、リッチなテキストベースのユーザインターフェイスも提供しています。2022年は、Ansible Navigatorが提供するハイブリッドなPlaybook実行環境の利用が進むものと予想しています。この記事が、みなさんの2022年の活動のお役に立てば幸いです。 それではみなさん、2022年もHappy Automation! :) Ansible Advent Calendar 2022 - ADVENTAR版 Ansible Advent Calendar 2022 - Qiita版

この記事は、「 Ansible Advent Calendar 2021 」の24日目の記事です。 レッドハット Ansibleサポートチームの八木澤(@hiyoko_taisa)と申します。世間はクリスマスムード一色ですが、皆様いかがお過ごしでしょうか。Ansibleサポートチームは、クリスマス・イブで浮かれる世間を尻目に、Ansible世界の平和を守るべく今日も奔走しておりました。 さて、今回の記事では、「Windowsモジュールの開発」について取り上げます。巷ではLinux用のモジュール開発についての情報は多く存在しますが、Windowsのモジュールについて日本語で書かれた情報はほとんどありません。私は以前、「 win_zip 」というWindows上でファイルをZip圧縮するモジュールを作成したことがあり、レビュアーにコードを魔改造されたりCIが通らずに泣きながら何度も修正したりして、なんとか「 community.windows 」コレクション内の1モジュールとしてリリースすることができました。今回はAnsibleコミュニティのWindows部長（自称）として、そこで得た知見を皆様にフィードバックしていければと思います。今回の記事はいろいろと書きたいことを詰め込みすぎて、想定よりはるかに長くなってしまいましたので、今回は前編として、年明けを目処に後編の方も公開させていただきます。ご了承ください。 また、この記事を読んで「Windows用のモジュール開発をしたい！」と思い立った 奇特な 方は、これらの公式ドキュメントにまず目を通してから実際に作業されることをおすすめします。 Developer Guide: https://docs.ansible.com/ansible/latest/dev_guide/index.html Windows module development walkthrough: https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_general_windows.html モジュール開発に至った経緯 そもそもAnsibleには「win_unzip」というzipファイルを展開するモジュールは存在していましたが、圧縮するモジュールはありませんでした。何度か同じようにzip圧縮を行うモジュールが提案されたことはあったようですが、実際に導入されるには至らなかったようです。win_zip実装を望むIssueもあり、「ならモジュール開発の経験を積むためにも自分で書いてみよう！」というのがそもそもの開発の動機です。 モジュールを開発する際には、別モジュールの機能として実装されていないか、作業中のものがないかなど最初にAnsibleのGitHubリポジトリを探してみましょう。私の場合は現在進行中のものはないようでしたので、すぐさま開発に着手することにしました。 なお、Windows用のモジュールが存在するコレクションは、Red Hatが公式にサポートするコアとなるモジュール群を含む「 ansible.windows 」と、コミュニティによって開発・メンテナンスされる「 community.windows 」の2種類が存在します。今回は、「community.windows」向けにリリースするモジュールの開発の話となります。 Windowsモジュールの構造 Windows用のモジュールは、Linux用のそれと若干構造が異なります。多くのWindowsモジュールは、以下の2つのファイルによって構成されます。それぞれ「 plugins/modules/ 」配下に配置されます。 <モジュール名>.py このPythonスクリプトは、主にドキュメントの生成のために利用されます。LinuxモジュールではこのPythonスクリプトがモジュールそのものですが、Windows上ではPythonを実行できないため、後述するPowerShellが利用されます。 以下は、私が記述した「 win_zip.py 」の例です。 DOCUMENTATION = r''' --- module: win_zip short_description: Compress file or directory as zip archive on the Windows node description: - Compress file or directory as zip archive. - For non-Windows targets, use the M(ansible.builtin.archive) module instead. notes: - The filenames in the zip are encoded using UTF-8. requirements: - .NET Framework 4.5 or later options: src: description: - File or directory path to be zipped (provide absolute path on the target node). - When a directory path the directory is zipped as the root entry in the archive. - Specify C(\*) to the end of I(src) to zip the contents of the directory and not the directory itself. type: str required: yes dest: description: - Destination path of zip file (provide absolute path of zip file on the target node). type: path required: yes seealso: - module: ansible.builtin.archive author: - Kento Yagisawa (@hiyoko_taisa) ''' EXAMPLES = r''' - name: Compress a file community.windows.win_zip: src: C:\Users\hiyoko\log.txt dest: C:\Users\hiyoko\log.zip - name: Compress a directory as the root of the archive community.windows.win_zip: src: C:\Users\hiyoko\log dest: C:\Users\hiyoko\log.zip - name: Compress the directories contents community.windows.win_zip: src: C:\Users\hiyoko\log\* dest: C:\Users\hiyoko\log.zip ''' DOCUMENTATION部分にモジュール概要などを、EXAMPLEに使用例を定義します。ここの記述についてはLinux用のモジュールと大きな違いはありません。 このファイルに記載された内容を元に、公式ドキュメントのモジュールのページなどが生成されますので、モジュールの実際の中身とドキュメントが食い違わないように注意する必要があります。特に開発初期の段階でドキュメント部分を作成すると、「こんな機能つくろう」と思ってドキュメントに書いたにもかかわらず、後になって実装を断念した結果、コード上は存在しない「幻の機能」が爆誕してしまう可能性があります。そうすると、ドキュメントを読んだユーザーが「なんか動かない」と困ってしまいますので、仕様変更や機能を追加した際にはちゃんとドキュメントに反映できているか気をつけましょう。 <モジュール名>.ps1 Windowsモジュールでは、PowerShellのスクリプトがモジュール本体となります。win_zipで言えば、実際にファイルやディレクトリを圧縮する処理を記述します。以下が「 win_zip.ps1 」の記述内容です。 #!powershell # Copyright: (c) 2021, Kento Yagisawa # GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) #AnsibleRequires -CSharpUtil Ansible.Basic $spec = @{ options = @{ # Need to support \* which type='path' does not, the path is expanded further down. src = @{ type = 'str' ; required = $true } dest = @{ type = 'path' ; required = $true } } supports_check_mode = $true } $module = [Ansible.Basic.AnsibleModule] :: Create( $args , $spec ) $src = [Environment] :: ExpandEnvironmentVariables( $module .Params.src) $dest = $module .Params.dest $srcFile = [System.IO.Path] :: GetFileName( $src ) $compressionLevel = [System.IO.Compression.CompressionLevel] :: Optimal $encoding = New-Object -TypeName System.Text.UTF8Encoding -ArgumentList $false $srcWildcard = $false # If the path ends with '\*' we want to include the dir contents and not the dir itself If ( $src -match '\\\*$' ) { $srcWildcard = $true $src = $src .Substring( 0 , $src .Length - 2 ) } If ( -not ( Test-Path -LiteralPath $src )) { $module .FailJson( "The source file or directory ' $src ' does not exist." ) } If ( $dest -notlike "*.zip" ) { $module .FailJson( "The destination zip file path ' $dest ' need to be zip file path." ) } If ( Test-Path -LiteralPath $dest ) { $module .Result.msg = "The destination zip file ' $dest ' already exists." $module .ExitJson() } # Check .NET v4.5 or later version exists or not try { Add-Type -AssemblyName System.IO.Compression.FileSystem -ErrorAction Stop } catch { $module .FailJson( ".NET Framework 4.5 or later version needs to be installed." , $_ ) } Function Compress-Zip ( $src , $dest ) { If ( -not $module .CheckMode) { If ( Test-Path -LiteralPath $src -PathType Container) { [System.IO.Compression.ZipFile] :: CreateFromDirectory( $src , $dest , $compressionLevel , ( -not $srcWildcard ) , $encoding ) } Else { $zip = [System.IO.Compression.ZipFile] :: Open( $dest , 'Update' ) try { [void][System.IO.Compression.ZipFileExtensions] :: CreateEntryFromFile( $zip , $src , $srcFile , $compressionLevel ) } finally { $zip .Dispose() } } } $module .Result.changed = $true } Compress-Zip -src $src -dest $dest $module .ExitJson() 基本的な構造や正確なお作法については、公式ドキュメントを参照してください。ここでは、いくつかかいつまんで解説します。 $spec = @{ options = @{ # Need to support \* which type='path' does not, the path is expanded further down. src = @{ type = 'str' ; required = $true } dest = @{ type = 'path' ; required = $true } } supports_check_mode = $true } ここでは、受け付けるパラメーター( src と dest )とその種類を定義しています。「 src もpathじゃないか」と思われますが、コメントにあるようにワイルドカードに対応できるように、ここでは strを指定しています。また、チェックモード(Dry Run)に対応しているモジュールであることも明示しています。 # If the path ends with '\*' we want to include the dir contents and not the dir itself If ( $src -match '\\\*$' ) { $srcWildcard = $true $src = $src .Substring( 0 , $src .Length - 2 ) } ここで、「*」で src が終了する場合にはそれがワイルドカードであるという判定を行っています。 ちなみに、 $module.ExitJson 関数を呼び出すと、処理が正常終了します。 $module.FailJson を呼び出すと、実行失敗(Failed)を返却できます。以下は、実際に圧縮を行う前に正常なパラメータが渡っているか判断するための処理です。 If ( -not ( Test-Path -LiteralPath $src )) { $module .FailJson( "The source file or directory ' $src ' does not exist." ) } If ( $dest -notlike "*.zip" ) { $module .FailJson( "The destination zip file path ' $dest ' need to be zip file path." ) } If ( Test-Path -LiteralPath $dest ) { $module .Result.msg = "The destination zip file ' $dest ' already exists." $module .ExitJson() } # Check .NET v4.5 or later version exists or not try { Add-Type -AssemblyName System.IO.Compression.FileSystem -ErrorAction Stop } catch { $module .FailJson( ".NET Framework 4.5 or later version needs to be installed." , $_ ) } src に指定されたファイルもしくはディレクトリが存在しない場合 dest で指定されたパスが .zip で終了していない(zipファイルではない)場合 同名のzipファイルが dest のパスに存在している場合 実行に必要な.NET Framework v4.5が存在していない場合 1,2,4の場合にエラーを返却、3の場合は実行の必要がないためそのまま終了するようにしています。4の.NET Frameworkのバージョン確認では、当初は.NETのバージョンを読み取り、そのバージョンの値が指定より小さかったらエラーとする処理としていましたが、レビュアーの方の指摘により、実際に Add-Type で呼び出してみて、失敗したらエラーとする方がよいとのことでその方式に変更しています。 いよいよ実際の処理であるCompress-Zip関数です。このモジュールのキモとなる部分であり、対象がディレクトリの場合とファイルの場合で異なる処理を実行するようにしています。Zip圧縮の機能そのものは.NET Frameworkで提供されているため、そちらを利用します。モジュール開発当初は、Powershellのコマンドレット(Compress-Archive)を利用する予定でしたが、ファイルサイズが2GBまでに制限されること、対象のOSバージョンが限られることから.NET FrameworkのZipFileクラスを直接利用する方式に変更しています。 モジュールの最後で実際に関数を呼び出し、終了処理を記述すれば完成です。 Function Compress-Zip ( $src , $dest ) { If ( -not $module .CheckMode) { If ( Test-Path -LiteralPath $src -PathType Container) { [System.IO.Compression.ZipFile] :: CreateFromDirectory( $src , $dest , $compressionLevel , ( -not $srcWildcard ) , $encoding ) } Else { $zip = [System.IO.Compression.ZipFile] :: Open( $dest , 'Update' ) try { [void][System.IO.Compression.ZipFileExtensions] :: CreateEntryFromFile( $zip , $src , $srcFile , $compressionLevel ) } finally { $zip .Dispose() } } } $module .Result.changed = $true } Compress-Zip -src $src -dest $dest $module .ExitJson() ちなみに、 CreateFromDirectory のときは事前にZipFileをOpenする必要はないのですが、 CreateEntryFromFile の場合はOpenしておく必要があります。最終的にはOpenしたZipFileをDisposeする処理になっています。 後編では、地獄のCIからリリースまでについて解説していきます。最後までお読みいただきありがとうございました。 Merry Christmas and Happy Automation!!

Red Hatで API & インテグレーションのスペシャリストとしてソリューションアーキテクトをしている杉本 拓です。 Red Hat Application Servicesのマネージドクラウドサービスとして、既に OpenShift API Management や OpenShift Streams for Apache Kafka が提供されていますが、今回は新しいマネージドクラウドサービスである OpenShift Data Science について、Red Hat Developerのブログ記事 4 reasons you'll love using Red Hat OpenShift Data Science の翻訳を通じて紹介をしたいと思います。 なお2021年12月23日時点では、OpenShift Data Scienceはまだベータ版となっております。 Red Hat OpenShift Data Science は、アップストリームの Open Data Hub プロジェクトから選りすぐりのコンポーネントで構成されたマネージドクラウドサービスです。Red Hat OpenShift Data Scienceが目指しているのは、データサイエンティストが機械学習 (ML) のワークロードを開発、トレーニング、テストし、その結果をコンテナとしてデプロイできるようにするための安定したサンドボックスを提供することです。この記事では、 機械学習 プロジェクトでOpenShift Data Scienceを使用する利点をまとめています。 コンテナでデータサイエンスが簡単に JupyterLab（図1）のようなツールは、すでにデータサイエンティストが自分のマシン上でモデルを開発する直感的な方法を提供していますが、コラボレーションや作業の共有には常に固有の複雑さが伴います。さらに、強力なGPUなどの特殊なハードウェアを使用する場合、自分で購入して維持しなければならないとなると、非常に高価になります。OpenShift Data Scienceに含まれるJupyterHubを使えば、データサイエンティストは開発環境をクラウド上に持っていくことができます。すべてのワークロードはコンテナとして実行されるため、チームメンバーとイメージを共有したり、チームメンバーが使用できる デフォルトのコンテナのリストに追加するだけで 、簡単にコラボレーションを行うことができます。GPUや大容量のメモリが急に必要になったとしても、ノートパソコンがサポートできる範囲に制限されませんので、簡単にアクセスできるようになります。そして、これまでと同じUXと開発ワークフローを維持することができるのです。 図1: JupyterLabノートブック セキュアに構築されたノートブックのイメージ ソフトウェアスタックは複雑になる傾向がありますが、機械学習に関わるものは特に複雑です。Pythonのエコシステムには、使用できるモジュールやライブラリが数多く存在するため、どのライブラリのどのバージョンを使用するかを決定するのは非常に困難な場合があります。図2が示すように、OpenShift Data Scienceには、データサイエンティストや Thoth adviser などのレコメンデーションエンジンからの知見をもとに構築されたノートブックのイメージが付属しています。これにより、データサイエンティストは、ランダムなアップストリームリポジトリから検証されていないイメージや安全でない可能性のあるイメージをダウンロードする心配をすることなく、新しいプロジェクトを素早く間違いのないやり方で開始することができます。 図2: JupyterHubで利用可能なノートブックのイメージ サードパーティーの機械学習ツールとの連携 お気に入りのツールやサービスをうまく連携させることができない状況に陥ったことは誰でもあるでしょう。OpenShift Data Scienceは、柔軟性を念頭に置いて設計されています。図3が示すように、幅広いオープンソースおよびサードパーティの AI/ML ツールをOpenShift Data Scienceで使用することができます。これらのツールは、データエンジニアリングや特徴抽出からモデルのデプロイや管理まで、機械学習のライフサイクルを完全にサポートします。お気に入りをそのまま使うことができるようになります。 図3: OpenShift Data Scienceで使用可能なサードパーティーツールとの連携 Operate First で蓄積された運用ノウハウ Open Data Hubは、あらゆる機械学習イニシアチブに必要と考えられるライフサイクル全体をカバーする30以上のAI/MLツールで構成される オープンソース コミュニティプロジェクトです。 Operate First イニシアチブは、最も使用されているコンポーネントのサブセットをオープンな環境にデプロイし、さらなる運用ノウハウを獲得して、アップストリームのプロジェクトを堅牢なものにすることを目的としています。OpenShift Data Science は、最もよく使用され安定しているコンポーネントのコアセットを取り上げ、 Red Hat OpenShift Dedicated および Red Hat OpenShift Service on AWS 上でマネージドクラウドサービスとして提供されます。つまり、データサイエンティストは、Red Hat OpenShift 上で複雑なワークロードを動かしているレッドハットの経験を活用しながら、迅速なイテレーションと検証に集中することができます。 まとめ ぜひ OpenShift Data Scienceの詳細を確認して 、こちらの デモ動画 で実際の動きを見てみてください。アップストリームのOpen Data Hubプロジェクトは、 https://opendatahub.io/ から自分で試すことができます。

Red Hat のソリューションアーキテクトの井上たかひろです。 Red Hat にはクラウドネイティブアプリの開発に役立つ、ソフトウェアのラインナップが充実していることをご存知ですか？ ここでは、それらのソフトウェア [Red Hat Application Services] に関する注目ニュースを、各製品技術に特化したソリューションアーキテクトが、ご紹介します。 今回は 2022/1月号となります。 想定読者 エンタープライズアーキテクト アプリケーション開発者 システムの提案をするSIerの方 特集1: あらためてRed Hat Middleware Core Services Collectionとは Red Hat MiddlewareのJBossなどのサブスクリプションを購入すると付いてくるRed Hat Middleware Core Services Collectionについて、ざっくりどういったもので、ご質問を頂く点などを整理してみました。 qiita.com 特集2: Karavan Designerの紹介！【いろいろPoCをしたいアーキテクト向け】 昨今のCloudNative界隈は、インフラがあってアプリケーションを入れる、ではなくアプリケーションコードを用意するとインフラが勝手に作られる、という構造をしているケースが増えてきています。プロダクトのPoCしたいんだけどコードを書かなくちゃいけない、でもアプリケーションエンジニアは忙しそうでたのめない・・・、というアーキテクト向けにKaravan Designerを紹介したいと思います。 rheb.hatenablog.com 特集3: OpenShift で始めるローコード開発 OpenShiftでローコードを始める場合どのような方法があるかということをテーマにMendixをベースに、サンプルアプリの作成やデプロイ手順などの解説になります。 rheb.hatenablog.com rheb.hatenablog.com 好評開催中！クラウドネイティブアプリ開発関連のWebinar全６回 Cloud Nativeを見据えたアプリケーションアーキテクチャとレガシーモダナイゼーション コンテナ時代の開発ツールチェインと開発プロセスのベストプラクティス クラウド/コンテナを前提とした時代のアプリケーション実行環境の選択 マイクロサービス/サーバーレス実践入門 これからのシステム連携を実現するデジタル基盤とアプローチ Cloud Nativeなデータパイプラインの作り方とオープンハイブリッドクラウドへの展開 各回とも、オンデマンドで視聴出来ます。（お名前とメールアドレス等の登録のみで視聴可能です） 下記リンクよりぜひご登録ください。 www.redhat.com 直近GAになった製品群 最近リリースとなった Application Services 製品群のリストをご紹介します。 見逃している製品が無いか、是非一度ご確認ください。 Camel Extensions for Quarkus 2.2 Camel K 1.6 Red Hat Fuse 7.10

Calendar for Ansible | Advent Calendar 2021 - Qiita の 22日目の記事になります。 Ansible Tower では Playbook をGitレポジトリ(Private可)から取得して使用できますが、Playbookと別のGit レポジトリ(Private可)にある Roleも同様に取得できるので紹介します。 Ansible Advent Calendar 2021 の 17日目にyo_C_taさんが似たテーマ(Private レポジトリにある collections の取得)を投稿していますので、合わせてどうぞ。 GitLab の private repository を ansible-galaxy collection install する - Qiita やりたいこと・想定 Ansible Tower を使う Playbook は Git レポジトリで管理しているものを使う Playbook が使う role は Playbook とは別の Git レポジトリで管理 Playbook が使う role は Playbook のレポジトリ内の requirements.yml で定義 Playbook も Role も Private な Git レポジトリで管理 以下、参考情報 requirements.yml (ansible-galaxyコマンドが使用) について Galaxy ユーザーガイド — Ansible Documentation Ansible Tower の Project機能(PlaybookのあるGitレポジトリを設定) (ansible-galaxy support) 14. Projects — Ansible Tower User Guide v3.8.5 Ansible Tower での role の取得 playbook のレポジトリの roles/requirements.yml に必要な role の git レポジトリのURLを記載しておくと Ansible Tower が Playbook のGit レポジトリを取得する際に role のレポジトリも取得してくれます。 ( ansible-galaxy install -r roles/requirements.yml コマンド相当) Playbook が Private Git レポジトリにある場合 対象の role が ansible-galaxy 等の公開されている場所であれば良いのですが git clone するのに認証が必要な Private Gitレポジトリを取得するには、ユーザ名/パスワードや秘密鍵等の情報を渡す必要があります。 Ansible Towerではこうした認証情報をCredentialオブジェクトとして作成し、Gitレポジトリの取得や、Playbook実行時のログイン情報に使用可能です。これはパスワード/パスフレーズ等の認証情報の中身を直接知らなくても扱えるようにするための仕組みです。 認証情報の画面例 Project (ここではお目当てのPlaybookがあるGit レポジトリ)を作成する際に、Gitレポジトリの認証情報(Credentialオブジェクト)を付与できるため、Private Git レポジトリも取得できます。 project 作成画面の例 ※URLはダミー ansible-galaxy コマンドで取得する role が Private Git レポジトリにある場合 PlaybookのGit レポジトリの取得に認証情報を適用するのは機能としてあるので、次に気になるのは requirements.yml に定義した role も Private Gitレポジトリにある場合 です。 requirements.yml の中に Role を取得するための認証情報も記載可能ですが、 Git管理下のファイルに認証情報を含めると、うっかり公開してしまう可能性もあり、避けたい です。 認証情報を中身が見えない形で取り扱えるのも Ansible Tower を使う理由の一つですので、 Playbook取得用の Credential をそのまま Role の取得でも使ってほしいですよね。 使ってくれます。 やってみた ここでは例として、以下のように roles/requirements.yml 内に認証情報は付与しない形でHTTPSの Git URLを指定します。(認証なしでは取得不可能な設定のGit レポジトリとします。) --- - src: https://gitlab.hogehoge/hogehoge_role.git scm: git このファイルが含まれている playbook の Git レポジトリを登録した Ansible Tower の Project を同期すると、requirements.yml を元に role を取得してくれますが、 認証情報を付与した上で実行 されます。 project 同期画面(url はマスクしています) オチ Playbookのレポジトリにしか認証情報が適用されないのではないか と思い、特殊な記述などがあるのか調べていたら、 こちらの issue に辿りつき、requirements.yml での role 取得にも対応していることを知りました。 github.com

レッドハットの杉村です。Ansible のテクニカルサポートをしています。 Ansible Advent Calendar 2021 の12月21日分として投稿します。 adventar.org 先日 Ansible Automation Platform 2.1 (AAP 2.1) がリリースされました。 rheb.hatenablog.com 昨日社内の勉強会で20分少々のプレゼンを行いまして、その資料を少々加工して公開します。旧バージョンから変わったところを主にまとめてみました。 speakerdeck.com 評価版はこちら Ansible Towerの評価ライセンスリクエストはこちらからご利用いただけます。 www.redhat.com Happy Automation!

はじめまして、Red Hat の 呉 と申します。8月に入社しまして、今回初めての投稿となります。 普段は RHEL をメインに、しばしば Ansible のテクニカルサポートをしています。 この記事はAnsible Advent Calendarの12月18日の記事です。 Ansible Tower は インターネット接続環境がある場合、Collections を Automation Hub プラットフォームと直接同期して利用する事ができます。 しかし、オフライン環境下でもあらかじめ Automation Hub プラットフォームから Collections をダウンロードしておくことで、Collections を利用することができます。 今回は Ansible Tower で Collections をオフラインで利用する方法についてみていきたいと思います。 まずは以下の Automation Hub にログインし、画面上部に見える collections をクリックします。 console.redhat.com するとよりどりみどり、たくさんの Collections が出てきます。今回は Red Hat が提供している rhel_system_roles コレクションを例として使ってみます。 コレクションを選択すると、このような画面が出てきますので、 Download tarball をクリックして tar ファイルをダウンロードします。 さてここからは Ansible Tower ノードでの作業です。 まず、先ほどダウンロードした tar ファイルの置き場所を作成します。今回は、ディレクトリ名を /opt/collections とします。 $ mkdir /opt/collections $ chown awx:awx /opt/collections また、このディレクトリ配下に tar ファイルを格納しておきましょう。tar ファイルは scp などであらかじめ Tower ノードへ送付済みとします。 [student@localhost ~]$ ls /opt/collections/ redhat-rhel_system_roles-1.7.3.tar.gz 次に、ansible 設定ファイルの defaults セクションに Collections のパスを指定してあげます。 /etc/ansible/ansible.cfg [defaults] collections_paths = /opt/collections/ ここまでできたら、ansible-galaxy コマンドを使ってローカルに Collections をインストールします。 ansible-galaxy collection install /opt/collections/redhat-rhel_system_roles-1.7.3.tar.gz -p /opt/collections/ これでインストールは完了しました。 せっかくなので、試しに今回インストールしたロールを動かしてみましょう。 まず、オフライン環境なので Ansible Tower ノードに直接プレイブックを作成していきます。 $ mkdir /var/lib/awx/projects/offline-collection redhat.rhel_system_roles.sshd ロールを利用して、操作対象のノードの /etc/ssh/sshd_config に X11Forwarding yes を入れるようにしてみます。 /etc/ssh/sshd_config ファイルを編集するような感覚で、vars に設定値を定義するだけなのでとても使いやすいですね。 /var/lib/awx/projects/offline-collection/test.yml --- - hosts: all vars: X11Forwarding: yes roles: - role: redhat.rhel_system_roles.sshd なお、本ロールの詳細は Automation Hub に詳しい説明がありますのでご参照してみてください。 console.redhat.com Playbook が作成できたら、Tower から Projects を作成しましょう。 続いてテンプレートも。/etc/ssh/sshd ファイルの設定を変更するので、ENABLE PRIVILEGE ESCALATION にチェックを入れましょう。 作成できたら、Launch します。 無事、redhat.rhel_system_roles.sshd ロールが実行されたようです！ いかがでしたでしょうか。インターネット接続がある環境と比べて一手間かかりますが、Ansible Tower がオフライン環境であっても、Collections を簡単に利用することができました。 Happy Automation !

みなさん、こんにちは。 12月にRed Hatのソリューションアーキテクトとして入社した小野です。 今回は、最新のOpenShift v4.9をAWSへインストールし、簡単なEdge Computingのデモアプリケーションを展開するまでの方法を紹介します。 OpenShiftは openshit-install というツールを使用して、また、Red Hat QuayはOperatorを使ってインストールする手順をまとめています。 簡単な手順で開発環境をすぐにセットアップでき、アプリケーションの開発に注力できます！ 大まかな流れは下記です。 1. OpenShiftをAWSへ展開 qiita.com 2. プライベートコンテナイメージレジストリの構築 (今回は、Red Hat Quayを使用しています) qiita.com 3. 開発環境にてEdge Cmputingのデモアプリケーションのコンテナイメージをビルド qiita.com 4. コンテナイメージをQuayへpushして、OpenShiftへ展開 qiita.com Edge Computingのデモアプリケーションは、テスト用の動画を入力し、任意のAIモデルで解析、解析結果をGUIで表示する、というものです。 GPUは勿論、CPUの環境でも実行できますので、気軽にお試しください！ みなさんのコンテナ活用の検討の一助となれる様、引き続き情報発信していきたいと思いますのでよろしくお願い致します！ 尚、OpenShift v4.9のリリースノートは以下をご参照ください。 docs.openshift.com

こんにちは！12月にソリューションアーキテクトとしてRedHatに入社した北村です。 前職でSREチームのマネジメントをしていましたので、このタイミングであらためてSREの簡単な概要をまとめてみました。 SRE始めてみたいけど全然分からない、とか、SRE導入に向けて上位層を説得するための材料が欲しい！といった方への一助になればいいなと思います。 qiita.com SREの全体像

ソリューションアーキテクトの蒸野（ムシノ）です。 前回に引き続き「OpenShift上でのローコード開発」についてお伝えさせて頂けたらと思います。 前回の振り返り 前回はローコードビジネスのメリットやローコードプラットフォームとしてMendixの紹介とMendixサンプルアプリを作成しました。 今回はMendixアプリをOpenShift上で動作させるためのクラスタ設定方法について言及させていただきたいと思います。 rheb.hatenablog.com また、改めてのご案内になりますが、Mendixの機能一覧について分かりやすいページがありましたので追加でご紹介させて頂けたらと思います。 jpn.nec.com MendixアプリのOpenShiftデプロイ手順 それではMendixマニュアルを参考にMendixアプリを OpenShift 上に公開するためのクラスタ設定を実施してみたいと思います。 同手順は正式には Mendix マニュアル（private-cloud-cluster）に作成方法が記載されていますので、詳細については下記をご覧いただけたらと思います。 docs.mendix.com 2.OpenShift環境の用意 2.1.オンラインLAB（OPEN） 前回の記事を参考にサンプルアプリを用意できましたら次は OpenShift 環境を準備しましょう。 今回はRedhat オンラインLAB（OPEN）環境で試したいと思います。 オンラインLAB（OPENTLC） 利用方法については下記記事を御覧ください。 レッドハットのパートナー【5】Red Hat OPEN に関する説明と利用手順 その2 - 赤帽エンジニアブログ 下記手順でプロビジョニングを行います。 カタログ ＞ OPENTLC Openshift ４Labs ＞ Hands On with OpenShift 4.8 プロビジョニングするまで少し時間がかかりますが待ちます。 完了すればプロビジョニング結果と共に各種情報がメールで通知されます。 オンラインLAB（OPEN）をご利用できない方向けのご案内 今回はオンラインLAB環境を使った手順でご説明しておりますが、無料の Developer Sandbox for Red Hat OpenShift という環境もあります。 詳細手順は下記記事でも紹介されておりますので是非ともお試しいただければと思います。 Kogito-Onlineでお手軽デシジョンサービス開発 - 赤帽エンジニアブログ 3.クラウド環境の設定 3.1.クラウド管理メニューの表示 オンラインLAB（OPEN）で準備した OpenShift への接続設定を行います。 Mendixの「Developer Portal」に戻り、一番左端にあるメニューアイコンをクリックします。 すると「Manage」＞「Cloud」という項目が表示されるためこれをクリックします。 3.2.クラスターマネージャの作成 メニューに「Cluster Manager」と表示されていると思いますのでこれをクリックします。 次にクラスタマネージャの「Register Cluster」をクリックし、クラスタ名などの入力項目があるクラスタ設定画面が表示されるので適宜入力します。 下記はMendixマニュアルにも載っている項目名で作成してみます。 Cluster Name：My Private Cloud Cluster Cluster Type：OpenShift Description：My OpenShift cluster すべて入力したら「Create」をクリックしクラスタを作成します。 3.3.クラスターマネージャの設定 クラスタの設定が成功すれば下記の様な画面になっているはずです。 それでは「Details」をクリックし、更に追加設定を行います。 3.4.ネームスペースの設定 次にネームスペースを作成します。 「Add Namespace」をクリックします。 ネームスペースを設定する画面が表示されます。 このネームスペースは OpenShift 上のプロジェクト名にもなるので分かりやすい名称を付けましょう。 Namespace：mendix-dev-workspace Install Type：Connected 入力が完了すれば「Done」をクリックします。 マニュアルにも記載がありますが、Mendix Developer Portal からアプリをデプロイする場合には「Connected」を選択します。 CLIから制御するだけの場合には「Standalone」を選択することになります。 また、ネームスペースは小文字しか受け入れられないためご注意ください。 3.5.Mendix CLI のインストール 次は Mendixのオペレータをインストールしていきます。 下記のようなMendix CLIをダウンロードする画面に遷移したと思います。ここから適切なCLIをダウンロードします。 「Donwnload Executable」をクリックするとダウンロードバージョンを選択する画面が表示されます。基本的には最新を選びましょう。 執筆時点（2021/12）では「2.1.0」を選択します。 これをクライアントPCにインストールします。 3.6.OCコマンドでOpenShift にログイン Mendixマニュアルに記載されていますが、MendixではOpenShiftに「Mendix Operator」と「Mendix Gateway Agent」をデプロイすることで OpenShift などの実行環境を提供します。 そのため、次はMendixオペレータ等を OpenShift にデプロイするため、OpenShift CLI（OCコマンド）でログインします。 オンラインLAB（OPEN）のプロビジョニング時にアクセス情報が共有されていると思いますのでこれを利用します。 Operator をインストールする際、Operatorをインストールできる権限でログインしておく必要があります。 oc login -u admin -p xxxxxxxxxxx https://api.cluster-xxx.xxx.sandboxxxx.opentlc.com:6443 Login successful. You have access to 74 projects, the list has been suppressed. You can list all projects with 'oc projects' Using project "default". 3.7.mxpc-cli コマンドの利用 OpenShift にログインできたら、次は Mendix CLIの「mxpc-cli 」からMendixオペレータをインストールしていきます。 Mendix CLIをダウンロードした画面に実行コマンドが記載されているのでこれをコピーしターミナルに入力します。 コマンド実行後、ターミナルに次のような表示がされていれば問題ありません。 もし表示されないという場合は mxpc-cli コマンドが正しく認識されているか確認が必要です。 3.8.ベースインストール それでは次にMendixオペレータのインストールするため、「1) Base Installation」をクリックします。 以下の項目を「options」に設定します。 Cluster Mode：connected Cluster Type：openshift Mendix CLIの画面が崩れていますが気にせず実施します。実行には影響はありません。 設定が終われば「Run Installer」をクリックします。 「Installer output」に実行ログが表示されます。インストールできれば最終行に「--Done」と表示されます。 もしエラーになるようなら OpenShift が動作しているか、クライアントからアクセスできるかなどをチェックします。 ここで一度「Save Installer」をクリックしYAMLファイルを保存しておきます。 インストール内容を OpenShift側で 確認してみましょう。 OpenShift コンソールを確認すると、設定したネームスペースである「mendix-dev-workspace」 が作成できているのが分かります。 また、Podも見てみましょう。 MendixのAgentとOperatorの名前がついたPodが作成されていることが分かります。 3.9.ネームスペースの設定 Mendix CLI は次のメニューにそのままでは遷移できないのでここで一度「Exit Installer」で終了します。 次にクラスタ環境設定に進みたいと思いますので先程同様「mxpc-cli 」コマンドで設定画面を表示します。 次は「2) Configure Namespace」を設定します。 Mendix CLIではいつくかの設定項目がありますが、OpenShift 上で動かすためには最低限以下の設定を行う必要があります。 Database Plan Storage Plan Registory 「Select items to configure:」で上記3項目をチェックし、「2) Configure Namespace」をクリックします。 Mendix マニュアルでは「Registory」は必須項目と指定がありませんが、実行時にレジストリURLがないとエラーになりますので設定するようにしましょう。 3.10.データベースの準備 Mendix CLIは次の設定画面に遷移されますが、一旦ターミナルを離れ OpenShift コンソールにアクセスします。 メニューで指定があったように、Mendixアプリを OpenShift 上で動かすにはデータベースとストレージが必要となります。 まずはデータベースの用意をします。今回はDev4Ddevs.com による PostgreSQL Operator でインストールするものとします。 OperatorHubから「PostgreSQL Operator」を「mendix-dev-workspace」 プロジェクトにインストールしましょう。 インストールをクリックします。 Operatorのインストール画面が表示されますが、すべてデフォルトのままインストールしましょう。 Operatorのインストールが完了すれば次はデータベースインスタンスの作成を行います。 表示されているDatabaseのインスタンス作成をクリックし、ここでもすべてデフォルトのまま作成を行います。 ここでトポロジーを見てみましょう。 下記のようになっていれば問題ありません。 3.11.ストレージの準備 次はストレージを用意します。 今回はAWS S3とします。 S3ストレージの用意方法についてはここでは詳細を示しませんが、Mendix CLIで設定するため「Access Key」と「Secret Key」が必要です。 また設定・実行時にはS3のバケット作成、削除権限、およびIAMのユーザ権限等が必要となります。これについてはMendixのマニュアルにS3のカスタムポリシーについての説明がありますので、これを参考に作成、Mendix CLIからアクセスできるように設定しましょう。 docs.mendix.com これで準備は整いました。 それではMendix CLIに戻り各種設定します。 3.12.データベースの設定 まずはデータベースの設定を行います。下に並んだメニューから「[2] Database Plan」を選択します。 次に左側に表示されている「Plan Details」に下記の項目を入力します。 Name：mendix-database Database Type：postgres データベースタイプを Postgres に設定すると、Postgresの詳細設定画面が表示されます。 下記のように設定項目に入力していきます。 Host：database Port：5432 Database Name：postgres Username：postgres Password：XXXXXXX（デフォルト設定したパスワードを指定します） これで一度「validate」および「Connection Validation」をクリックし設定の確認を行います。 valid 、もしくは successfully tested! になっていれば問題ありません。 3.13.ストレージの設定 次にストレージの設定を行います。 データベースの設定同様、メニューから「[3] Storage Plan」を選択します。 左側に表示される「Plan Details」に下記の項目を入力します。 Name：mendix-storage Database Type：amazon-s3 ストレージでもデータベース同様 amazon-s3 を選ぶと S3 の詳細設定画面が表示されます。 下記のように設定項目に入力していきます。 Bucket region：ap-northeast-1 Access Key：XXXXXXXXX（設定済みのAccess Keyを指定します） Secret Key：XXXXXXXXX（設定済みのSecret Keyを指定します） その他の項目はデフォルトのままとします。 入力後「validate」および「Connection Validation」をクリックし設定の確認を行います。 ここでも valid 、もしくは successfully tested! になっていれば問題ありません。 3.14.リポジトリの設定 最後にリポジトリの設定となります。メニューから「[5] Registry」を選択します。 左側に表示される「Registry Details」に下記項目を入力します。 Registry Type：openshift4 openshift4 では特に設定項目はありませんので、これで完了です。 3.15.ネームスペース設定の有効化 それではこれまで設定してきた設定項目を有効にします。「[8] Review and Apply」を選択します。 レビュー画面が表示されるので「Evaluate Configuration」をクリックします。 Status が Valid になっていれば問題ありません。 これを「Write YAML」 でローカルPCに保存します。 その後「Apply Configuration」をクリックすることで設定が反映されます。 これでMendix CLI を使った設定は完了です。 3.16.クラスタマネージャのステータス確認 Mendixクラスタマネージャ画面 に戻ります。 ネームスペースの設定・有効化を行ったことで、クラスタ設定の下に設定したネームスペースが見つけられると思います。 この「Details」をクリックして現在のステータスを確認してみましょう。 ステータスが Connected で表示されていれば接続できていることを示しています。 ネームスペースの下にいくつかのメニューがあります。このPlansを確認してみましょう。 下記のように先程 Mendix CLI で設定したデータベースやストレージの設定が見えるはずです。 Plans が Deactive と表示されていますがこれで問題ありません。 ここで active にするとアプリ側の環境設定でデータベース等の設定項目が見えなくなるため、このままにしておきましょう。 これでクラスタの設定は完了しました。 次回以降 いかがでしたでしょうか？ Mendixのプライベートクラウドクラスタの設定方法について、具体的にイメージすることができたのではないでしょうか？ それでは次回は最後回になります。Mendixサンプルアプリの環境設定にクラスタ設定を反映させ、OpenShift上でMendixアプリが動作することを確認してみたいと思います。 本文中に登場した OpenShift に関わる用語については、下記マニュアルを参考いただけたらと思います。 * 第1章 Web コンソールへのアクセス OpenShift Container Platform 4.8 | Red Hat Customer Portal * 第1章 OpenShift CLI (oc) OpenShift Container Platform 4.4 | Red Hat Customer Portal * Operator OpenShift Container Platform 4.8 | Red Hat Customer Portal * 2.4. Topology ビューを使用したアプリケーション構成の表示 OpenShift Container Platform 4.6 | Red Hat Customer Portal

OpenStackやOpenShiftなどのCloud製品を担当しているソリューションアーキテクトの輿水です。 約３ヶ月ぶりにRed Hat OpenStack Platform（以降RHOSP）についてです。今年の9月15日に Red Hat OpenStack Platform 16.2 がリリースされております。前回の記事を書いた時点でリリースされていたのですが、10月開催の「KubeCon + CloudNativeCon North America 2021」に合わせて公式発表するので、公に書くのはちょっと待ってね、という状況でございました。 Red Hat OpenStack Platform 16.2はRed Hat OpenShiftとの緊密な統合を実現し、ネットワーク容量、セキュリティ機能、ストレージ、パフォーマンス、効率の向上とともに、新しいアプリケーションと従来のアプリケーションの両方を並行して実行できるような環境を提供します。 www.redhat.com OpenShift Container Platformに関して、パブリッククラウドにOpenShift Container Platformをインストールするのと同じ様に、OpenStackによるプライベートクラウドにOpenShiftをインストールして使えるようにするOpenShift on OpenStackという方式があります。最新のOpenshift 4.9はRHOSP 16.2でサポートされます。サポートされるRed Hat OpenStack PlatformとOpenshift Container Platformのバージョンの組み合わせ表は以下の通りです。 access.redhat.com RHOSPのライフサイクル RHOSP 16以降は、16.0、16.1のようなマイナーバージョンが存在します。それぞれでサポート期間が異なりますが、RHOSP 16という括りでは16.0の一般提供開始日である2020年2月20日から16.2のELS終了日である2025年4月30日までの5年の長期サポートを提供します。16をご利用になり、2024年以降もサポートが必要な場合は、ELSを利用できる16.2を利用していただく必要があります。 16.2のベースはコミュニティ版Trainで、Ussuriの機能のいくつかがバックポートされています。また、16.1ではホストOSのバージョンがRHEL 8.2でしたが、16.2ではRHEL 8.4になります。 バージョン RHEL 一般提供開始日 フルサポート終了日 サードパーティ認定期間終了日 メンテナンスサポート終了日 ライフサイクル終了日 延長ライフサイクルサポート（ELS）アドオン終了日 フルサポート 16.2 8.4 2021年9月15日 2023年4月30日 2022年5月31日 2024年4月30日 2024年4月30日 2025年4月30日 16.1 8.2 2020年7月29日 2022年4月30日 2021年5月31日 2024年4月30日 2024年4月30日 - 16.0 8.1 2020年2月20日 2020年10月27日 - - - - 延長サポート 13 7.9 2018年6月27日 2019年12月27日 2019年12月27日 2021年6月27日 2021年6月27日 2023年6月27日 10 7.7 2016年12月15日 2018年6月16日 2018年12月31日 2019年12月16日 2019年12月16日 2021年12月15日 ライフサイクルに関する 日本語版ドキュメント を見ると「ライフサイクル日付」の表の下付近に小さく 「16.1 は、Red Hat Enterprise Linux 8.2 でのみサポートされます。メンテナンスサポートの期間は、延長アップデートサポート (EUS) アドオンサブスクリプションが必要です。」 という記載があります。「延長ライフサイクルサポート（ELS）アドオン」ではなくて「延長アップデートサポート (EUS) アドオン」です。「OpneStackを使っていてEUSという単語が出てきたことがあっただろうか？」と思う方もいらっしゃるかもしれません。文章を図にすると以下のようなイメージになります。 RHOSP 10, RHOSP 13ではメンテンスサポート期間にアドオンサブスクリプションが必要になることはなかったのですが、RHOSP 16.1と16.2ではメンテナンスサポート期間においてアドオンサブスクリプションが必要になります。これはRHOSPとRHELが密接に統合されて、RHELの特定のバージョンを長期にわたって利用・サポートするために必要になっています。 16.1を2022年5月1日以降も利用してメンテナンスサポートを受ける場合は、この延長アップデートサポート (EUS) アドオンサブスクリプションが必要になります。それまでに、16.2へマイナーアップデートしていただければ、アドオンサブスクリプションは必要ありません。なお、 16.1のEUSアドオンサブスクリプションは有償になります 。16.2のEUSアドオンサブスクリプションについては現時点では未定です。16.1のEUSアドオンサブスクリプションの価格については弊社営業までお問い合わせください。 メンテナンスサポート期間に提供される内容は、これまでと変わりません。フルサポートの内容から「新機能のバックポート」と「追加のパートナープラグインの導入」を除いたサポートを提供します。 16.1から16.2へのアップデート方法は「 Keeping Red Hat OpenStack Platform Updated 」に記載されています。16.2にアップデートを行う場合は、利用している16.1を最新にしておく必要があります。（ 日本語版のドキュメント もありますが現時点では16.2-betaの情報になっていますので、最新情報としては英語版のドキュメントを参照してください） RHOSPアップグレードパス 現在13をご利用中で延長ライフサイクルアドオンを追加していただいている場合は、2023年6月27日まではサポートされますので、その間に16.2以降への移行をご検討ください。13から16.2へのアップグレード方法には、インプレースアップグレードとParallel Cloud Migrationがあります。 インプレースアップグレード 既存環境をアップグレードします。追加のハードウェアやサブスクリプションは不要です。 アップグレードのための フレームワーク を提供しています。 Parallel Cloud Migration 既存環境に並列に最小構成の新規環境を作成し、ワークロードを移行する方式です。追加のハードウェアとそのハードウェア用にRHOSPサブスクリプションが必要になります。 この移行方法はお客様環境に依存する点が多いため、弊社のコンサルティングサービスの一環として提供します。 ワークロードの移行時に、ワークロードの停止時間が必要になります。 10をご利用の場合は延長ライフサイクルも終了となります。10→13のインプレースアップグレード方法（Fast Forward Upgrade）も提供されております。 13→16において、何らかの理由（3rdベンダープラグインの対応状況やVNFの対応状況など）で13→16.2ではなく13→16.1というアップグレードを選択する場合、Support Exceptionという処理プロセスが必要になりますので、弊社までご連絡ください。

こんにちは、Red Hatでソリューションアーキテクトをしている石川です。 前回の記事からやや間が空いてしまいましたが今回もKnativeについて改めて入門していきたいと思います。 前回の記事はこちら rheb.hatenablog.com 本編に入る前に、Knative関連の最近のトピックをご紹介させて下さい。 この度なんとKnativeがCNCFのincubatingプロジェクトに移管されることが発表されました！ knative.dev 現在はまだ申請中のステータスとのことなので正式にCNCF配下となるのは少し時間がかかると思いますが、これからKnativeがますます盛り上がっていくことが期待されますね。 TLDR; Knative ServingではKPA(Knative Pod Autoscaler)という仕組みでスケーリングを実施。HPAと挙動が違うので注意。 Knative/Serviceの設定で複数のRevisionにトラフィックをルーティングできる。 Knativeのルーティングを実現するためKourier(中身はenvoy)が使われている。 Knative Servingの特徴 前回の記事ではKnative Servingの基本的な内容に触れましたが、今回はやや発展編としてKnative Servingの特徴についていくつか焦点を当て見ていきたいと思います。 具体的には、 * Knativeのオートスケールの仕組み * 複数のRevisionへのトラフィックルーティング * アプリケーションPodにトラフィックが到達するまでの仕組み という3つのトピックについてご紹介しようと思います。 それでは早速見ていきましょう。 Knativeのオートスケールの仕組み Knativeはアクセスがない時はPodを0までスケールインし、アクセスが増えるとPodをスケールアウトするという特徴を持っています。 このオートスケールの仕組みはKPA(Knative Pod Autoscaler)というカスタムリソースにより実現されています。 Kubernetesを普段から使われている方であれば、Podのスケーリングの仕組みとしてHPA（Horizontal Pod Autoscaler）を思い浮かべるかと思いますが、Knativeではデフォルトの設定としてHPAではなくKPAを使用しています。 KPAを使うことで多くの場合で適切にスケールを行い、必要な処理を実行することができますが、スケーリングの挙動について注意すべきこともあります。 それは何をトリガーにスケールを実施するか、という点です。 HPAの場合、一般的にはPodのCPUやメモリの使用量に閾値を設定しておき、その値を超えた場合にPodがスケールアウトする挙動となります。またCPU、メモリ以外にもPrometheus等で取得したカスタムメトリクスを利用するパターンもあります。 一方でKPAはデフォルトでPodへの実行中のリクエスト数（concurrency、in-flight requestsととも）の閾値が設定され、その値を超えた場合にスケールするような挙動となります。 concurrencyを使うのではなくrps（requests per second=1秒ごとのリクエスト数）をスケールのトリガーにすることもできますが、どちらもリクエスト数に基づく設定となるため、実行したいサーバーレスのアプリケーションによってはKPAでは上手くスケールできないこともあります。そのため、アプリケーションの性質に応じてKPAとHPAと使い分けることが重要となります。 試しにKPAでのオートスケールを実践してみましょう。 以下のコマンドは hey というツールを使い並列リクエストを実行する例です。 # hey -z 30s -c 50 \ "https://blog-django-py-knative-serving.apps.mycluster.gzqc.p1.openshiftapps.com/" \ && oc get pods -l app.kubernetes.io/name=blog-django-py ここで hey コマンドの -c 50 はリクエストを実行するworkerの数を、 -z 30s でリクエストの実行時間を指定しています。 コマンド実行の結果は以下となります。 Summary: Total: 30.0245 secs Slowest: 6.9209 secs Fastest: 0.0048 secs Average: 0.0580 secs Requests/sec: 861.0630 Total data: 51654294 bytes Size/request: 1998 bytes [中略] NAME READY STATUS RESTARTS AGE blog-django-py-00003-deployment-65ccd7dcf7-4vbz8 2/2 Running 0 28s blog-django-py-00003-deployment-65ccd7dcf7-6bhj4 2/2 Running 0 30s blog-django-py-00003-deployment-65ccd7dcf7-h6vpd 2/2 Running 0 26s blog-django-py-00003-deployment-65ccd7dcf7-jv26l 2/2 Running 0 24s blog-django-py-00003-deployment-65ccd7dcf7-rzgn5 2/2 Running 0 28s blog-django-py-00003-deployment-65ccd7dcf7-shvwb 2/2 Running 0 28s blog-django-py-00003-deployment-65ccd7dcf7-v4sf8 2/2 Running 0 28s blog-django-py-00003-deployment-65ccd7dcf7-wd5n7 2/2 Running 0 28s 実行結果の後半部分からアプリケーションのPodがスケーリングし複数実行されているのが確認できました。 Knativeのスケーリングに関する設定は、Revision単位ではKnative/Serviceの spec.template.metadata.annotations に記載を行うことで実施可能です。 全てのKnative/Serviceに設定を反映させる場合は、Namespace knative-serving にあるConfigMap config-autoscaler に設定を追記することで反映されます。 詳細については Knativeの公式ドキュメント をご参照下さい。 是非色々と試行錯誤をして最適な設定を見つけてみて下さい。 複数のRevisionへのトラフィックルーティング 前回の基礎編でデプロイされるアプリケーションのバージョンはRevisionという単位で管理されるということをお伝えしました。 Knative ServingではKnative/Serviceの設定で各Revisionにどの程度トラフィックを割り当てるのか決めることができます。これを利用することでサーバーレスアプリケーションにおいてもカナリアリリースなどの高度なリリース手法を実現することができます。 具体的に設定の例を見てみましょう。 以下ではKnative/Serviceの spec.traffic 以下に各Revisionの情報とそれぞれのトラフィックの割合を定義しています。 ここではカナリアリリースを想定し、最新のRevisionに全体のトラフィックの5%、一つ前のRevisionに95％が振り分けられるようにしています。 spec: traffic: - latestRevision: true percent: 5 tag: latest - revisionName: "blog-django-py-00002" percent: 95 tag: current このyamlを適用すると、OpenShiftコンソールでは以下のような形でトポロジーを見ることができます。 意図した通りにアクセス先が振り分けられていることを確認できました。 この時、それぞれのRevisionのPodは、エンドポイントへのアクセスではなくPodへのアクセスがあって初めて起動するような形となります。 アプリケーションPodにトラフィックが到達するまでの仕組み これまでお伝えしてきた通り、Knative Servingではサーバーレスアプリケーションのエンドポイントにアクセスした時の動きとして、Podの数が0であればスケールしたり、Revisionごとにトラフィックを割り振ったりなど、様々な機能を提供しています。 こうした機能を提供するため、どのようなオブジェクトが関連しているか詳細を以下の図で表しました。 やや複雑な絵になりますが、ポイントとして以下を押さえれば大丈夫です。 1) 外部向けエンドポイント公開や、Revision間のトラフィックルーティングはNamespace knative-serving-ingress 内のオブジェクトで実施されている 2) クラスタ内部向けのエンドポイントはアプリケーションのNamespace（上記の場合 app-ns ）で公開されている 3) サーバーレスのアプリケーションPodはアプリケーションのNamespaceで実行される 4) アプリケーションPodの数が0の場合、Namespace knative-serving の activator / autoscaler を介してPodをスケールする 外部/内部向けに公開されたエンドポイントにアクセスすると、まずはNamespace knative-serving-ingress の 3scale-kourier-ingress という名前のPodにアクセスすることとなります。 これは Kourier というKnativeでトラフィックルーティングを行うコンポーネントで、実態としてはIstioでも利用されている envoy です。 ルーティングの設定は同じNamespaceにある net-kourier-controler というPodに管理されており、このPodはControl planeとしてアプリケーションのNamspaceにあるKnative/Ingressというカスタムリソースを見てenvoyに動的に設定を反映させています。 このKnative/Ingressは、 Knative/Service -> Knative/Route -> Knative/Ingress といった親子関係を持っており、大元のKnative/Serviceが作成されるとその情報を元に自動で作成されるカスタムリソースです。 エンドポイントからKourier Podに到達したトラフィックはアプリケーションNamspaceのDefault/Serviceを経由し、Namspace knative-serving にある activator というPodにアクセスします。この activator はその名の通り、アプリケーションPodを起動するトリガーとなる役割を持っており、 autoscaler を経由してアプリケーションPodをスケールさせます。 アプリケーションPodが起動すると同じNamspaceにあるEndpontsオブジェクトが更新され、Default/Serviceを介してPodへのアクセスが可能となります。 まとめ Knative Serving発展編いかがだったでしょうか。前回に比べるとやや深掘りした内容となりましたが、あくまでもKnative/Serviceカスタムリソースさえ作成してしまえばサーバーレスのアプリケーションを実現できてしまうというのがKnativeの良いところです。 次回はKnativeのもう一つのコンポーネントであるKnative Eventingについてご紹介し、イベント駆動でのサーバーレスアプリ実行方法をご紹介したいと思います。

みなさんこんにちは、レッドハットでソリューションアーキテクトをしている暮林といいます。 今回の記事ではいろいろなサービスを接続してPoCをしてみたいアーキテクト向けに、Karavan Designerの紹介をしたいと思います。 Karavan Designerとは？ そもそも apache Camel Kとはなんぞや？ DSLが書けない！ そこでKaravan Designer！ 早速つかってみる ３秒おきに「Hello World from Camel K!!!」とログに出すルートを書いてみる 次回予告 Atrlas Mapを組み合わせて実践的なPoCをする！ Karavan Designerとは？ ずばり apache Camel KのDSLをグラフィカルに書くためのツールです。VSCODEのプラグインとして利用したときはこんな見た目。 そもそも apache Camel Kとはなんぞや？ この記事が参考になります。 apache Camel Kの源流はapache camelプロジェクトです。 apache camelはDSLというプログラムと設定ファイルの中間ぐらいの言語を書くことで、あるサービスとあるサービスを糊のようにくっつけることができる便利な存在です。 rheb.hatenablog.com DSLが書けない！ 引用した記事で以下のようなDSLがあります。 from("timer:tick?period=3s") .setBody().constant("Hello World from Camel K!!!") .to("log:message") Camel DSLは基本的に真っ直ぐな処理ルートを（いわゆる正常系）をつなげて書くので、大体の人が何となくよめるのが特徴です。このDSLは３秒おきにルートを起動して、"Hello World from Camel K!!!"をログにだすというものですね。 しかし！読めることと書けることには結構な距離があります。特に普段アプリケーションを書くことを主業としていない、アーキテクトやSREはなおさらです。（この記事を書いている私も書けません） そこでKaravan Designer！ これまでにもCamel DSLを書くためのデザイナー的な存在はいくつかありましたがこれといった決定打がなく（失礼）、エンジニアは使い慣れたIDEで補完が使えるJava DSLをそのまま書く、というのはあるあるでした。 そんななかで2021年10月にプレビューリリースされたKaravan Designerは群をぬいて使いやすい印象です。なにせVSCODEのプラグインとして導入できるため、ファーストステップのハードルがとんでもなく低いです。 早速つかってみる VSCODEのプラグインから「Karavan」を検索してインストールしてみてください。 次は空でいいのでVSCODEからフォルダひらきましょう。フォルダを開いていないとKaravan Designerをひらくメニューが出ません。 開いたフォルダを右クリックなどからサブメニューをひらくと、Karavan: Create YAMLがあるのでクリックしてください。 画面上部にファイル名を入れるダイアログがでるので「hello」とでも入れてエンターを押してください。 デザイナーが開けば準備完了です。 ３秒おきに「Hello World from Camel K!!!」とログに出すルートを書いてみる 真ん中にデカデカとそびえたつ黄色いボタンをプッシュして新しいフローをつくります。 このようにいろいろなパブリッククラウドのリソースをルートの開始にとれることがひと目で見えてワクワクしますが、流れ出る涎をこらえて右上の検索ボックスに「timer」といれてください。(この時点でブログ離脱してあれこれしはじめてもOKです） なんの面白みもないTimerソースがでてきましたので、クリックしましょう。 こんな状態になったことでしょう。Timerを開始としたつまらない何かができそうですね！ 何やら右側にパラメーターが見えています。 はてなマークをクリックするとこのように、つまらないTimerソースのパラメータの解説をしてくれます。いちいちこんなつまらないソースについてぐぐりたくないので、とても助かりますね。 このようにいれてみました。Content Typeはデフォルトが text/plainなので放置します。 この時点ででここまで書けたことになります。次はログ出力ですね。 from("timer:tick?period=3s") .setBody().constant("Hello World from Camel K!!!") ルート上の+ボタンを押すと、再度テンションがあがる一覧がでてきますが、涙を飲んで右上に「log」と書いて「Producer」タブを押してください。 このようにログ出力のStepが追加されました。何やら右側に赤いアスタリスクが見えますね。 もとのDSLをリスペクトしてmessageと入れましょう。ただのロガーの名前なので何でも良いです。（12/14現在若干センシティブな話題） これで完了です。できあがったルートの中身をみるためにフォルダから「hello.yaml」をクリックしてみましょう。 このようなCamel KのYAML形式のDSLができています！ - from: uri: 'kamelet:timer-source' steps: - to: uri: 'log:message' parameters: period: 3000 message: Hello World from Camel K!!! 実行自体についてはDesigner紹介の本論からはずれてしまうので扱いませんが、JBangという仕組みをつかって簡単にローカル実行することもできます。 JBangについてはこのあたりをどうぞ。 rheb.hatenablog.com 次回予告 Atrlas Mapを組み合わせて実践的なPoCをする！ こんなつまらないルートではCamel KそのもののPoCしかできないじゃないか！とお怒りの言葉をいただきそうなので、次回予告をしておきたいと思います。 もっと実践的なこんなルートについて掘り下げていきます。apache KafkaのTopicを読んで、何らかの編集をして別Topicに戻すというルートです。イベントドリブンアプリケーションの肝オブ肝です。 現実的なルートでは、受け取ったメッセージをそのまま後ろにパスするのではなく、なんらかの編集が必要になるでしょう。ちょっと違うJSONの形に編集し直すようなケースです。 これはプログラムで書くにはまったくもって退屈な作業です。一般的にはETLツールが得意としている領域ですが、実はAtlas MapというOSSでGUIからマッピングが書けてしまいます。 AtlasMapは、もともとは実行可能jarをサクッとダウンロードしてローカル起動して、マップを書き終わったらファイルをエクスポートして終わるといったものでしたが、いまどきらしくVSCODEから起動することができるようになりました。（これもプレビューです） 次回はKaravan DesignerとAtlasMapを組み合わせて、ノーコードでapache KafkaのPoCができるような使い方の紹介をしたいとおもいます。 お楽しみに！ rheb.hatenablog.com

レッドハットの杉村です。Ansible のテクニカルサポートをしています。毎月1つは何か書くことを目標にしています。 Ansible Advent Calendar 2021 の12月12日分として投稿します。 adventar.org Ansible Automation Platform (AAP) では、自動化のためのさまざまなジョブを実行することができます。プレイブックを動かすためのジョブテンプレートが主なものとなりますが、ジョブテンプレートはこのような要素から構成されています。 インベントリー (接続対象の情報) プロジェクト (プレイブックなどを入れたディレクトリ) 実行環境 (ansible のコマンドや必要なライブラリなどが入った Podman のコンテナイメージ) 認証情報 外部変数 このジョブテンプレートを実行するためには、まずプロジェクトディレクトリ全体をジョブごとに実行ディレクトリにコピーして、ジョブ同士でリソースの競合がないように閉じた環境を作ります。以前の Ansible Tower と呼ばれていたものの古いバージョンでは同じディレクトリのものを同時にいじろうとするとロックするようになり、ジョブの起動が待たされるということもありました。 認証情報はパスワードやSSHの秘密鍵などの情報をデータベースに暗号化して保存しています。暗号化には Django の機能を使っています。 docs.ansible.com ジョブの実行時にこの認証情報を取り出して、実行ディレクトリの中にファイルとして一時的に出力して使うのですが、このような秘密鍵のデータを動的にファイルシステムの中でやりとりするという動きは珍しいようで、セキュリティのためのスキャンサービスに検知されて動作が阻害されることがあります。 特に今月に入ってからは特定のそのような製品を導入したときにその問題が頻発しており、既知のものであれば問い合わせの内容に応じて案内をしています。 内部的にもさまざまなサービスが複雑に協調して動作していますので、他の製品はその動作仕様を完全に理解していることはありませんし、そのような他の製品はできるだけ追加でインストールされないようにお願いしています。 テクニカルサポートでは日々さまざまなトラブルによる問い合わせを受けます。「何もしていないのに動かなくなりました」というのも数多くありまして、だいたいはそのようなスキャンサービスが正常な動作を阻害しているために発生します。 何かそのようなものを一緒に導入されているときに思うような動きが得られないということがありましたら、まずは止めて様子を見てみることをお勧めします。 他にも「容量」という概念がありまして、同時にいくつのジョブを実行できるのかというのを CPU やメモリのリソースから算出して、インスタンスが安定稼働を維持できるように上限を設ける仕組みがあります。スキャンサービスでプロセスなどが停止されたりファイルが削除されるようなことはなくても、他の製品を一緒に稼働させていることによって当初算出した「容量」が圧迫され、より少ないジョブの稼働数でも動作が不安定になってしまうこともあります。そのようなパフォーマンスの問題はサポートとしても再現するのが難しく、まずは他のものを止めてくださいという案内をすることになります。サーバの数を節約するために複雑な構成を取ってしまった場合に、そのために運用が難しくなるというお問い合わせを受けることがあります。 docs.ansible.com 今回は製品はできるだけあるがまま普通に使いましょうというお話をしました。今年も一年を通してだいたい毎月何か一つ以上は紹介してこれたと思います。来年もよろしくお願いします。 おわりに Ansible Automation Platform の評価ライセンスリクエストはこちらからご利用いただけます。 https://www.redhat.com/ja/technologies/management/ansible/try-it Happy Automation!

Red Hatのさいとうです。この記事はAnsible Advent Calendarの12月9日の記事です。今回は、地味であまり知られていないAnsible Collectionsのメンテナの仕事についてご紹介しようと思います。 Ansible Collectionsとは Ansible2.9までは、Playbookを処理するエンジン部分と、モジュールやプラグインなどコンポーネントをあわせて、AnsibleというOSSプロダクトとして提供していました。 この提供形態が、2.10で大きく変更されて、現在のAnsibleでは以下の2つのサブコンポーネントに分離され、この2つをあわせたものをAnsibleとしてバージョニングして提供しています。 2.9以前からAnsibleを利用している方に馴染深い2.x.zというバージョニングは、現在では1.のAnsible Coreのバージョンとして採用されています。 Ansible Core : ansible-playbookコマンドなどのPlaybookを実行するためのエンジン部分と、核となる少数のモジュール、プラグイン群 Ansible Collections : Ansible Coreに含まれないモジュール、プラグイン、ロールをまとめてジャンル毎にまとめてたもの Collectionsごとに専用のリポジトリが存在していて、Ansible Coreとは独立したリリースサイクルをもっています。そして、他のOSSと同様に、それぞれのCollectionsには、リポジトリを管理するメンテナが任命されています。 Ansible Collectionsの場合の任命プロセスは、特に決まっておらず、なんとなく大量にPullRequestなげていると、現行メンテナから他のPullRequestのレビュー依頼がくるようになって、レビューを続けていると、「ちょっとメンテナやってみない?」といった感じで誘われることが多いようです。また、それぞれのCollectionsのリポジトリに、Issueとして「メンテナ募集!」といったタイトルでIssueがオープンされて、メンテナを公募することもあるようです。この場合も、「過去にどれくらい積極的に係わってくれているのか」という点が問われます。 Ansible Collectionsへの係わり方 CollectionsもOSSですので、皆さんさまざまな係わり方をしているのではないでしょうか? Collectionsを利用する バグや機能追加などのフィードバックをする 修正や機能追加などをコード実装する 報告されたバグや、投稿された修正・機能追加コードをレビューする Collectionsのリポジトリを管理する Ansible Collectionsのメンテナのお仕事は、5.にあたります。厳密には報告されたバグや機能追加リクエストにしたがって、コードを書いたり修正したりするといった役割は、実はメンテナの仕事ではありません(実際にはしてるけど)。 Ansible Collectionsメンテナのお仕事 メンテナのお仕事ガイドラインは、Ansibleのコミュニティーチームからの ガイダンス にまとめられていますが、ほとんどは口伝です。 [ansible.posix]コレクションを例にして、ひっそりと行っているメンテナのお仕事をご紹介します。 利用者から寄せられるバグや機能追加などのフィードバックのトリアージとクローズ 利用者が報告してくれた(してくれた <- 感謝のお気持ち。ここ大事)バグレポートや機能追加リクエストを確認して、適切にラベリングします。ansible.posixでトリアージに利用している主なラベルは以下の通りです。 needs_triage : モジュールの作成者やメンテナが報告された情報を精査している(してないかもしれないけど、とりあえず付与) needs_verified : バグの再現やワークアラウンドの検証、機能追加リクエストであれば既存の機能などかないかどうかを確認中 needs_info : 報告者からの情報が足りない。通常はIssueのコメントで追加情報を求めている verified : 確認完了 bug : はい、それバグです feature : お、その機能あるといいね waiting_on_contributor : 再現してくれるひとやコードを書いてくれるひと求む has_pr : IssueとセットになったPullRequestが存在していからリンクしておいたよ Collectionsによっては、 module や plugin といった、レポートされた対象のコンポーネントにしたがってラベルを付与している場合もあるようですが、僕は基本的に上記のラベルだけでやりくりしています。細い管理が苦手なタイプなので。 オープンされたものは、いつかクローズする時がくるものです。PullRequestによって不具合が解消されたり機能が追加された場合や、報告者の環境に依存した問題が原因で不具合が発生していたといった場合は、コメントしたうえでIssueをクローズしています。 IssueやPullRequestのトラッキング PullRequestのレビューをレビュアにお願いしたり、Issueの調査が難航しそうであれば、モジュールのAuthor(だいたい見てない)に連絡して調査の進展をうながすといった交通整理を行います。 また、PullRequestのCIテストが失敗しているような場合は、テストログをチェックしてPullRequestのオーナーに変更依頼を出すといったことも行います。 Ansible Coreの変更に対する対応 Ansible Collectionsは、CIテストにAnsible Coreのansible-testコマンドを利用しています。そのため、Ansible Core側でansible-testの仕様が変更されると、その影響の直撃を受けます。Ansibleが1つのプロダクトだった時代は、特にこの影響はありませんでしたが、Ansible CoreとCollectionsに分離されたタイミングから、Ansible Coreの仕様変更を常にトラッキングして、その変更に追随する必要がでてきました。 このように、Ansible Coreの変更によってCollectionsが何らかの影響を受ける場合、Ansibleのコミュニティーチームが、以下のサイトにIssueとして報告をあげてきます。これを常時チェックして、その変更の影響を吸収する措置を考えて、CI環境のパラメータを調整するといった作業がこれにあたります。 https://github.com/ansible-collections/overview/ 例: Changes impacting Collection Contributors and maintainers #45 PullRequestのマージ レビューが完了したPullRequestに gate ラベルを付与します。メンテナによって gate ラベルが付与されると、そのPullRequestは再度CIテストが実施されて、これにパスすると自動でマージされる仕組みです。 Collectionsでは、コードのマージプロセスに、プロジェクトゲートシステムの Zuul を利用してるため、メンテナが直接PullRequestをマージすることはありません。 リリース計画の策定と実行 メンテナの間で、「そろそろやろうか?」とリリース計画を策定します。通常は、これもオープンにIssueで議論されます。以下は、community.generalコレクションの例です。 Releasing, Versioning and Deprecation #582 Collectionsでは、良きタイミングでリリースタグを打ってアーカイブを作成します。Ansible Coreと分離されたおかげで、各Collectionsのメンテナが独自のリリースサイクルで新バージョンをリリースできるようになっています。ありがたい。 新バージョンのアーカイブは、自動で Galaxy にアップロードされるので手間いらず。 最後に、IRCとコミュニティニュースレター用のIssueを更新してリリース完了です。 The Bullhorn - contribute content for developer newsletter #546 まとめ メンテナとしての仕事も、整理してみると意外にやることが多く、自分でも少し驚いています。 僕の場合は、幸いなことにAnsibleチームに在籍しているということもあって、Red Hatでは、このようなOSSのAnsibleに貢献する活動が公認されています。超絶優秀な同僚にサポート業務を丸投げしてリリース対応といったこともできる環境です。こういう会社のカルチャー本当に大事。 いつもカバーしてくれている同僚と、それを認めてくれている会社に感謝しつつ、今回の記事を締めたいと思います。みんなありがとうね!