Red Hatでソリューションアーキテクトをしております荒木です。久しぶりの投稿ですが、今回は、OpenShiftの導入事例セミナー等を観ることができるサイトの紹介をしたいと思います。 OpenShift 事例セミナーは、その名のとおり事例にフォーカスしウェビナー形式で配信しております。なかなか聞けないOpenShift ユーザーの生の声もきけるので、実践面で参考になるかと思います。また、その様子は見逃し配信されてるので今からでも要チェックです！（ご覧いただくためにはアカウント登録が必要です） www.redhat.com 同サイトでは「OpenShift詳解セミナーシリーズ」も併設されており、OpenShift の特徴的な機能の紹介も観ることができます。OpenShift についてより具体的なイメージを持つことが出来るとおもいます。こちらも合わせて要チェック！！ 事例シリーズで個人的に特におすすめしたいコンテンツはパネルセッションのコーナーです。ユーザ様が出演＆コメントをいただいてるので、とても生々しい内容になっているかなと思います。 Red Hat OpenShift 事例セミナーシリーズ 第3回 NTT東日本様 − 映像AI解析プラットフォーム 編 グラレコ：No3.パネルセッション Red Hat OpenShift 事例セミナーシリーズ 第4回 日本総合研究所様 − 金融業界におけるデジタル変革の実現 編 グラレコ：No.4パネルセッション こうやってみると事例として紹介できる機会も増えてきているので、コンテナ技術のビジネス面での活用も新たな段階に到達しつつあるのかなと感じます。 さて、2021年も残りあとわずかということで、今年の振り返りもかねてOpenShift 事例セミナーシリーズのサイトを紹介しました。 また、先日開催されました OpenShift Commons Gathering Japan 2021 のオンデマンドサイトも近日中に公開される予定です。そちらからもコンテナ技術の活用やコンテナ基盤の導入事例をチェックしてください！

レッドハットの杉村です。Ansible のテクニカルサポートをしています。毎月1つは何か書くことを目標にしていますが11月は書けなかったため、これを11月分にします。 Ansible Advent Calendar 2021 の12月3日分として投稿します。 adventar.org 昨日、米国時間12月2日に Ansible Automation Platform 2.1 のリリースがアナウンスされました。原著者の許可を得ましたので、日本語でも紹介します。リンクされているドキュメントやビデオは全て英語です。 www.ansible.com Red Hat Ansible Automation Platform 2.1 の一般提供を発表できることを嬉しく思います。これは、今年の夏にリリースされ、 Ansible Fest 2021 で発表された Ansible Automation Platform 2.0 Early Access の続編です。Red Hat Ansible Automation Platform 2.1 は、顧客がさらに柔軟な自動化アーキテクチャとユースケースのためにより簡単に導入できるようにする主要な機能を導入します。 Ansible Automation Platform 2.1 は、エンタープライズでの自動化する方法を長年にわたって再考したものの集大成となっています。 最新バージョンは Red Hat カスタマーポータル から直接ダウンロードするか、 red.ht/try_ansible で無料トライアルにサインアップすることでご利用いただけます。Ansible Automation Platform は、企業向けに設計された、あなたがご存じの Ansible です。 Ansible Automation Platform 2 が発表された9月の Andrius Benokraitis のブログの投稿 を要約し、2.0から2.1へのいくつかの重要な機能拡張を紹介していきます。 まずは一般情報から Ansible Automation Platform の ライフサイクルのページ が更新されました。 今後は、Ansible Automation Platform のマイナーリリースには、Red Hat Subscription Management のためのリポジトリが含まれます。Ansible Automation Platform サブスクリプションが必要とするものです。2.0 Early Access 版をご利用の場合は、こちらのコマンドでリポジトリを切り替えてください。 # subscription-manager repos --disable=ansible-automation-platform-2.0-early-access-for-rhel-8-x86_64-rpms # subscription-manager repos --enable=ansible-automation-platform-2.1-for-rhel-8-x86_64-rpms 次に、いくつかの公式ドキュメントの更新を紹介 2.1 でリリースされた新しいガイドです。 Installing and Configuring Central Authentication Guide Automation mesh Guide Ansible Platform Operator Installation Guide こちらは従来のリリースに大きな追加がされたガイドです。 Ansible automation hub: How to deploy a high availability automation hub Red Hat Insights for Ansible Automation Platform: Introduction to Reports Ansible Security Automation Guide: How to automate network intrusion detection and prevention systems 更新されたリリースノートなど、全てのドキュメントは オンライン で参照いただけます。(いまのところは英語です) Ansible Automation Platform 2.1 の新機能: automation mesh Automation mesh （ ドキュメント ）：これは Ansible Automation Platform に追加された最新の機能であり、1.2 の isolated node 機能に代わるものです。 2.0 で導入された実行環境 (execution environment) と 2.1 の automation mesh を組み合わせることにより、自動化コントロールプレーンと実行プレーンが完全に分離され、世界中で自動化を簡単に拡張できるようになります。 単一のデータセンターで自動化を実行することに縛られることなく、自動化を実行対象のできるだけ近くで実行できるようになりました。 automation mesh を使用すると、ノースカロライナ州ダーラムのオートメーションコントローラーに実行を展開しながら、実行対象のすぐ隣に実行ノードを作成できます（たとえば、南アフリカのヨハネスブルグにあるブランチオフィス）。 Automation mesh はこのような機能を追加します。 動的なクラスタの容量。 必要に応じて実行能力を増やすことができます。 グローバルなスケーラビリティ。 実行プレーンはネットワークの遅延や接続の中断に対して回復力があり、不安定なネットワークにも強いです。 安全な自動化。 実行ノードとコントロールノードの間の双方向の通信は完全な TLS による認証とエンドツーエンドでの暗号化を行います。 Shane McDonald と Craig Brandt によるこの automation mesh demo をご覧ください。Ansible Fest 2021 のものです。(22:38 にスキップしてください)。この automation mesh はさらに今後もこのブログで深く紹介していく予定ですので、ご期待ください。 更新された automation execution environments (実行環境) 最近、 automation execution environments (自動化実行環境) は、はるかにポータブルで柔軟なパッケージとして 1.2 までの Ansible Engine から置き変わりました。 Ansible Automation Platform 2.1には、Red Hat コンテナレジストリで利用できるようになった、事前に構築され、サポートされている自動化実行環境の更新されたセットがあります。 これらのイメージは、環境内のさまざまな容量で使用でき、Ansible Automation Platform サブスクリプションの一部として提供されます。 サポートされているすべての自動化実行環境は、 ansible-automation-platform-2 と呼ばれる親リポジトリでホストされています。 便宜上、3つの自動化実行環境すべてがバンドルされた 2.1 インストーラーの一部として含まれるようになりました。 あらかじめビルドされた実行環境が更新されました Minimal (ee-minimal-rhel8) - UBI8 と python-3.8 の上に構築された Ansible Core 2.12 が含まれています。 このコンテナイメージにはコレクションは含まれていません。 これをベースイメージとして使用して、カスタムコレクションまたは Ansible automation hub で利用可能な Red Hat Ansible 認定コンテンツコレクションを使用して、追加の自動化実行環境を構築できます。 Supported (ee-supported-rhel8) - これは、automation controller で使用できるデフォルトのコンテナイメージです。 Minimal のコンテナイメージの上に構築され、Red Hat によって公式にサポートされているすべての更新された Ansible コンテンツコレクションが含まれています。 Ansible 2.9 (ee-29-rhel8) - Ansible 2.9 と必要なすべての Ansible についての依存するパッケージが含まれています。 このコンテナイメージは、Ansible Automation Platform 1.2 (旧 Ansible Tower 3.8) から Ansible Automation Platform 2.1 への移行を計画しているお客様に最適です。 インターネットへの接続がない環境でのインストール Ansible Automation Platform 2.1リリースでは、インターネットへの接続がない環境でのインストールでも、Red Hat OpenShift 用の Red Hat Ansible Automation Platform Operator がサポートされるようになりました。 詳細については、 公式の製品ドキュメント を参照してください。 統合的な認証機能の追加 エンタープライズソフトウェアソリューションでは、シングルサインオン (SSO) の必要性がますます重要になっています。 Ansible Automation Platform 2 は引き続き追加の関連コンポーネントをリリースするため、標準化された方法でコンポーネント間を簡単に認証する必要があります。 まず手始めに、SSO を活用する最初のものとして、private Automation Hub や Red Hat Ansible Automation Platform Operator から導入できるようになりました。この拡張機能によって、将来のリリースで Ansible Automation Platform の他のコンポーネントについても SSO に対応していけるようになっていく基礎となります。 振り返り: Ansible Automation Platform 2 の構成の概要 Ansible Automation Platform 2は、企業が組織全体で自動化を拡張できるようにするツールとコンポーネントのスイート全体を導入しました。 Ansible Automation Platform は、サポート付きの単なるアップストリームコマンドライン Ansible パッケージではなく、Ansible の単なるグラフィカルユーザーインターフェイスでもありません。 利用可能なさまざまなコンポーネントの詳細を示す高レベルの図をご覧ください。 よく知られている ansible-* バイナリコマンドラインツール以外にも、多くのコンポーネントがあります。 Red Hat は、顧客が自動化を作成、管理、拡張するのに役立つ複数のコンポーネントを開発しました。 今回リリースされたものをご紹介します。 実行環境ビルダー ( ドキュメント ): これは、自動化の作成者が自動化をコンテナ化されたイメージにすばやくパッケージ化して、テスト済みの自動化実行環境にするのに役立つコマンドラインツールです。 Ansible コンテンツツール : これは、自動化コンテンツの作成を支援する完全にサポートされているコンポーネントを指します。 たとえば、コマンドラインツール ansible-test は、IT自動化担当者が自動化コンテンツ ( ドキュメント ) をテストするのに役立ちます。 他にも他のツールに加えて、 VS code の Ansible 用機能拡張 についても取り組んでいます。 Ansibleコンテンツコレクション : Ansible Automation Platform 2 では、自動化コンテンツ (ロール、プレイブック、モジュール、プラグインなど) を実行コンポーネント ansible-core (ansible-playbook など) から分離しました。 これによく似ているのは、お気に入りのモバイルゲームの最新バージョンを入手するために、スマートフォンをアップグレードする必要がないというようなことです。 自動化コンテンツを分離することで、Ansible Content Collection の更新を非同期的にリリースし、自動化を継続的に改善できます。 コレクションとは何かを理解するためのヘルプが必要な場合は、この YouTube ビデオ をご覧ください。 これまで次のような複数のドメインにわたって新しい自動化コンテンツを継続的に追加してきました。 Infrastructure ( Red Hat , Windows ) Cloud Native ( Kubernetes と Red Hat OpenShift ) Public Cloud ( AWS , Azure , GCP ) Private Cloud ( VMware ) Network Automation ( Arista , Cisco , Juniper , Vyos ) Security Automation ( Checkpoint , Cisco , IBM ) 認証され完全にサポートするコレクションの一覧については、 console.redhat.com の Ansible automation hub のページ をご覧ください。 オートメーションコンテンツナビゲーター ( ドキュメント ): インタラクティブなテキストベースのユーザーインタフェース (TUI) を含む、自動化作成者向けの新しいコマンドラインコンポーネントです。 自動化コンテンツナビゲーター (ansible-navigator) を使用すると、Ansibleの専門家は、自動化実行環境をサポートすることで、従来の Ansible のコマンドと同じような使い方(ansible-playbook など) の運用知識を簡単に再利用できます。 オートメーションコンテンツナビゲーターを使用すると、プレイをすばやくズームインおよびズームアウトしたり、出力をその場でフィルタリングしたりできるため、自動化エンジニアがこれまで慣れ親しんできたプレイの実行結果の把握がより見やすくなります。 また、同僚が作成したこのビデオ ansible-navigator を使用して簡単にコンテンツを作成する もお勧めします。 自動化コントローラー ( ドキュメント ): Ansible Automation Platform 用の Web ユーザーインターフェイス (webUI) および API (アプリケーションプログラミングインターフェイス) です。 これは、以前は Red Hat Ansible Tower と呼ばれていたコンポーネントに代わるものです。 この新しいアーキテクチャではコントロールプレーンと実行プレーンを分離することにより、グラフィカルインターフェイスと同じノードに関連付けられなくなることで、古いアーキテクチャに比べて実行能力を向上させることができます。 このアーキテクチャの変更の詳細については、Craig Brandt のブログ投稿 Ansible Automation Platform 2 の新機能: 自動化コントローラー を読むことをお勧めします。 自動化実行環境 ( ドキュメント ): 簡単に言えば、これは Ansible コントロールノードとして利用できるコンテナイメージです。 これには、Python パッケージの依存関係 (Amazon Web Services の場合は boto3 など)、 システムレベルの依存関係 (Linuxパッケージのgcc、jqなど)、および Ansible Playbook の自己完結型ランタイム環境を作成するための ansible-core にバンドルされた Ansible コンテンツコレクションが含まれています。 コマンドラインのansible-navigator と WebUI / API駆動の自動化コントローラーはどちらもこの実行環境を実行できるため、自動化プレイブックの作成とテストから、運用や本番環境への移行までをより迅速かつ簡単に行うことができます。 自動化実行環境の詳細については、ブログ投稿 Ansible Automation Platform 2の新機能: 自動化実行環境 をご覧ください。 Private automation hub ( ドキュメント ): 自動化作成者が自身のオートメーションコンテンツを共同で公開し、その組織内で Ansible コードを利用できるようにするものです。 ハイブリッドクラウド全体でニーズが拡大するにつれて、組織としても Ansible コンテンツのライフサイクルを管理および制御できるようになりました。 このコンポーネントは完全に自己ホスト型であり、自動化の作成者とオペレーターに Ansible コンテンツコレクションと実行環境の両方を提供できます。 private automation hub に関する私のブログ を読んで、深く掘り下げることをお勧めします。 Automation hub ( コンソール ): これは、private automation hub に対応するものです。完全にサポートおよび認定されたすべての Ansible コンテンツコレクション用に、整理された自動化コンテンツリポジトリとして console.redhat.com で公開されています。 IT運用者は、Ansible automation hub からオンプレミスの private automation hub に特定のコレクションを同期し、使いたいコレクションを管理することができます。 Red Hat Insights for Ansible Automation Platform ( コンソール および 製品ページ ): このオプションの SaaS で提供されるサービスは、console.redhat.com で利用できます。 これにより、自動化アーキテクトは複数の Ansible Automation Platform クラスタから単一のビジュアルダッシュボードにデータを集約できるため、アーキテクトは複数の自動化イニシアチブ全体の傾向を分析および発見できます。 Red Hat Insights for Ansible Automation Platform は、Ansible Automation Platform から非同期で新しい機能を絶えず追加するホスト型サービスです。 ただし、2.1 のリリースと同時に導入されたレポートと呼ばれる新機能があります。 レポートは、消費用の分析データとダウンロード可能なPDFを提供します。 たとえば、時間の経過とともにどのホストがどのジョブテンプレートによって変更されたか、組織ごとに分類されたホストや、組織ごとに分類されたジョブとタスクなどを確認できます。 自動化サービスカタログ ( コンソール ): 上記のサービスの他にも、console.redhat.com 上の SaaS で提供されるサービスとして Ansible Automation Platform サブスクリプションに含まれる自動化サービスカタログがあります。 自動化サービスカタログは軽量のITサービス管理として機能し、自動化の消費者は自動化をカタログアイテムとして注文できます。 自動化サービスカタログを使用すると、複数の自動化コントローラーを Web UI の1つのプッシュボタンに集約して、サイト固有の複雑さを抽象化できます。 これにより、組織全体で簡単に利用可能なワンタッチ方式で自動化を採用できます。 また、承認とチェックアウトシステムがあり、企業の自動化に一定レベルのガバナンスを追加します。 Ansible Automation Platform Operator ( ドキュメント ): Red Hat OpenShift 用のネイティブで完全にサポートされている Operator です。これにより、Operator Hub を介して Ansible コンポーネントを Red Hat OpenShift に簡単にインストールすることができます。 自動化コントローラーと private automation hub の両方が、単一のオペレーターに含まれています。 心のこもったビデオ Automated Live, エピソード03 をぜひご覧ください (5:29 までスキップしてください)。 次は何から始めればいいですか? あなたが初心者であっても、歴戦のベテランであっても、あなたの自動化の知識を高めるためにさまざまなリソースを用意しています。 自己学習 - ブラウザ内で完結できる Ansible Automation Platform の自己学習のための演習があります。 試用版サブスクリプション - オンプレミスでインストールしたいですか? Ansible Automation Platform の全ての機能をお試しいただける試用版サブスクリプションをご利用いただけます。 開発者ライセンス - あなたの自宅で学習するための開発者ライセンスが無料で提供されていることはご存じですか? 登録して Red Hat が提供する全ての最新のツール、テクノロジー、コミュニティにアクセスしてください。 Red Hat Ansible Automation Platform YouTube チャンネル に登録してください。 Colin McNaughton の Automated Live を見てください。 Red Hat Ansible Automation Platform の Twitter アカウント をフォローしてください。質問や自慢したいことなどありましたら、ぜひツイートしてください! 著者 Sean Cavanaugh Seanは、Ansible のプリンシパルプロダクトマーケティングマネージャーであり、コンピューターネットワークの構築と自動化に10年以上の経験があります。 Sean は以前、Cumulus Networks と Cisco Systems の両方で働いており、顧客がネットワークインフラストラクチャを展開、管理、自動化するのを支援していました。 彼はノースカロライナ州チャペルヒルに妻と子供たちと一緒に住んでおり、@IPvSean からツイートしています。 翻訳者より Ansible 2.9 がこの年末で EOL になったらどうなるの? と世界中から毎日のように問い合わせを受けていました。ようやく正式公開版として Ansible Automation Platform 2.1 がリリースできたことで、とても喜ばしく感じています。 踏み台として使われてきた isolated node が automation mesh として大きく生まれ変わったのは非常に大きなアップデートだと思います。 実行環境 (execution environment) がコンテナ化されたことで、Ansible Tower での virtual environment の作成に悩まされることもなくなりました。個別に作成方法がお客さんによって異なって Python のバージョンも一定しないというのは、サポートする側としてはとても苦しいものがありました。以前記事を書きましたが ansible-builder で簡単に作れますので、お試しください。 rheb.hatenablog.com また、RHSSO を同時にインストールして automation hub の SSO に使えるようになったというのも大きいです。automation controller (旧 Tower) の認証には SAML や LDAP などの外部認証も幅広く使われているのですが、今後 RHSSO に統一されていくことで、認証に詳しいチームとうまく分担できればいいなと Ansible のサポートとしては期待しています。 なお、各製品コンポーネントの日本語での呼び方は一定しておらず、公式にこう呼びますというものもありません。英語表記もご参照ください。 ご興味持たれたことや質問などありましたら、#ansiblejp のタグで tweet していただけるとうれしいです。 Happy Automation!

こんにちは、ソリューションアーキテクトの蒸野（ムシノ）です。 今回からOpenShift上でローコードを始める場合どのような方法があるかということをテーマにご紹介をしてみたいと思います。 少し長いので、数回に渡ってお伝えさせていただけたらと考えています。 ローコードのビジネスメリット いろんな記事で言及されている内容ですのでここでは簡単にまとめる程度にしますが、ノーコード・ローコードの市場規模は2022年には2兆円を超えると言われています。 ガートナーの予想では2025年には開発アプリケーションの70％がノーコード・ローコードに切り替わると予想されています。 また、IT部門に属さないシチズンデベロッパーの台頭が予測され、その数はITエンジニアの4倍の数に達すると言われています。 なんとなく分かったようで、理解しづらい、具体的に分かりづらい点もあるかもしれません。 では次のようなメリットではどうでしょうか？ 非エンジニアでもアプリ開発が可能であり、開発速度が圧倒的に早い ユーザは開発ベンダーに「できません」と言われることもなく、理想のアプリを入手できる 2025年の崖に対応すべくデジタル人材不足へ対応できる、可能性がある 老朽化したシステム刷新への対応力が維持できる、可能性がある 特に「2025年の崖」に対処できている企業はいまだ一部の企業に留まっている状況かと思います。 一般的に考えると未対応企業ではIT投資額を減らしていくことが考えられます。するとどうしても基幹システム周辺の老朽化したシステムに予算を割り当てることは難しくなります。 ここにノーコード・ローコードなどの利用者が利用する立場からアプリケーション開発、保守を行うというシナリオが現実性を帯びてきます。 シチズンデベロッパーが開発可能なシステム領域を整備し、ローコード開発・保守プロセスを仕掛けていく良いタイミングではないでしょうか。 ローコードプラットフォームの Mendix Mendix はグローバルではローコードプラットフォームとして認知されている製品であり、日本でも取り扱い事例や開発プラットフォームに採用するなどの動きが活発になってきています。 mendix.buildsystem.jp ガートナー、フォレスターなどではローコードプラットフォームのリーダとしても位置づけています。 また、重要な点としてはマルチプラットフォームに対応している点があります。 ローコードプラットフォームでマルチプラットフォームで対応している製品は少なく、Mendix のアプローチは弊社の マルチクラウド ・ ハイブリットクラウド という考え方にマッチします。 特記事項 ここではあくまでもOpenShiftに統合できるローコードプラットフォームといった観点から本文に掲載しております。 同製品の詳細については本記事には掲載しないことご承知いただけたらと思います。 また、Mendixに関するご質問についてもお受けすることができないため、Mendixサポートや取り扱い企業にご連絡のほどお願いいたします。 Mendixのユースケース 次にMendixはどんなアプリケーションを開発できるのかが気になるところですよね。 Mendix の開発アプリケーションソリューションギャラリーがありますのでこちらを参照ください。 www.mendix.com Mendixのアーキテクチャ Mendixは開発ポータルを提供しその上で、「Mendix Studio」「Mendix Studio Pro」と行った開発エディタを使うことでアプリケーションの開発が可能です。 www.mendix.com 開発後アプリケーションを公開することになりますが、MendixランタイムはOpenShiftやKubernetesなど最新のクラウドプラットフォームと互換性のあるコンテナで動作するように設計されています。そのため先程言及していたように、プライベートクラウド、ハイブリットクラウド、マルチクラウドなどの環境でMendixアプリを実行させることができます。 OpenShift上にデプロイできるローコードプラットフォームのメリット では、OpenShiftにデプロイした場合のメリットを考えてみます。 ローコードの開発効率に加え、開発基盤としてのアジリティを期待できる システムの自律運用化、運用一貫性による運用効率が期待できる 公開環境構築の速度向上、CICDパイプライン短縮によるリリース速度向上が図れる マルチクラウド・ハイブリッドクラウドに対応するため、アプリケーションのポータビリティ性が維持できる このようにローコードの強みとOpenShiftのメリットの相乗効果によるメリットが考えられます。 MendixのOpenShiftデプロイ手順 前置きが長くなってしまいましたが、それではMendixアプリをOpenShift上に公開する場合の方法について実施してみたいと思います。 今回は事前準備編としてサンプルアプリを作成するまでとします。 1.Mendixアプリの作成 1.1.アカウント作成 まず最初は下記のリンクから、Freeアプリが作成できるアカウントを取得します。 https://signup.mendix.com/link/signup/?source=direct 1.2.開発ポータルへのログイン 必要項目を入力すれば無事アカウントが作成されるはずですので、 Mendix開発ポータルにログインしてみましょう。 最初「Developer Portal」は下記のような画面になっているかと思います。 環境によっては「Studio Tour」アプリもなくブランクになっているかもしれません。 1.3.サンプルアプリの作成 それではOpenShfitにPublishするサンプルアプリを作成してみましょう。 まずは「Developer Portal」の右端にある「Create App」をクリックします。 1.4.アプリテンプレートの選択 ブランクのアプリか、アプリテンプレートを選べる画面が表示されます。 今回はアプリテンプレートから「Timesheet Approval App」を選んでみます。 1.5.サンプルアプリの初期設定 「Timesheet Approval App」にマウスオーバすると「Select Template」が表示されるのでクリックします。 テンプレートアプリの詳細画面に遷移するので、右下に表示されている「Select This Template」でアプリを作成します。 アプリケーション名とアプリケーションアイコンのカスタマイズ画面が表示されますので、任意の名称とアイコンを選択します。 今回はアプリ名を「TimeSheet-TestApp」とし、アイコンカラーをレッド、アイコンをカレンダーにセットします。 これでサンプルアプリを作成する準備が整いました。 それでは右下にある「Create App」をクリックしてアプリを作成します。 アプリの作成に数分がかかりますので、作成されるまで少し待ちます。 1.6.サンプルアプリのプレビュー アプリが作成されると下記のような画面が表示されると思います。 ここで作成されたアプリを少し動作確認してみましょう。 右上にある「Edit in Studio」をクリックします。 すると下記のようなアプリを編集できるエディター画面が表示されるはずです。 ここで右上にある「Preview」をクリックして、アプリの動作を確認してみます。 1.7.サンプルアプリの確認 プレビュー画面でアプリが表示されていると思います。 試しに「New」でタイムシートを作成するなど、一通りアプリを試してみましょう。 ここまでアプリの詳細な設定やコードの修正などは全く行っていませんが、それなりに動作可能なアプリができあがっています。 次回以降 いかがでしたでしょうか？ 今回はまずはローコードのメリットやローコードプラットフォームの紹介、サンプルアプリ作成といった流れまでをご紹介させて頂きました。 それでは次回は、OpenShift 上にMendixで作成したサンプルアプリを動かすよう各種設定を行っていきます。

Red Hatのさいとうです。早いもので、今年もAnsible Advent Calendarの季節がやってきましたね。 例年、僕はみなさんがクリスマスを楽しんでいるときに、ひとり黙々とAdvent Calendarの25日の欄を埋めるのを1年最後の楽しみにしていたのですが、今年はなんと初日(12/1)と最終日(12/25)の枠を確保してしまいました。それでは Ansible Advent Calender 2021 の初日の記事をお届けします。 2021年のAnsibleとわたしの内容を振り返る Ansible Advent Calendar初日の今日は、 元記事 の中で触れた2021のAnsibleの技術面でのトピックについて振り返ってみようと思います。 元記事では、2021に予想される大きな動きとして以下の2点をあげました。 Private Automation Hub Container Runtime for Ansible この2つのコンポーネントは、2021年7月にリリースされた Red Hat Ansible Automation Platform 2.0 early access (以降AAP2.0)で本格的に導入されています。当時はAnsible Festでの発表のみで、「具体的にどのような役割を担っているのか」や、「どのような形で利用者のみなさんに提供されるのか」は触れられていませんでした。 以降では、元記事の振り返りとして、この2つのコンポーネントが利用者の皆さんに「何」を「どのように提供するのか」をご紹介します(日本時間の2021年11月30日現在)。 尚、AAP2.0は、アップストリームの Ansibleプロジェクト 配下にあるいくつかのコンポーネントを、よきタイミングでまとめたダウンストリーム版ですので、ここで紹介しているお話は、アップストリーム版のAnsibleやAWX、GalaxyNGといったプロダクトでも体験することができます。 Private Automation Hub Ansible Towerのジョブランタイムで利用するコンテンツの中でModule、Plugin、Roleをまとめたものが Ansible Collections です。Private Automation Hubは、このCollectionsのプライベートリポジトリ機能を提供します。 Ansible Galaxy や、 Red Hat Automation Hub が提供している機能を、利用者が独自の環境に構築できるわけです。アップストリーム版は Galaxy NG として公開されています(注1)。 Private Automation Hubでは、利用者が独自に作成したCollectionsをプライベートリポジトリにアップロードして提供できるだけでなく、Ansibible GalaxyやRed Hat Automation Hubで公開されているCollectionsのリポジトリからコンテンツをダウンロードしてキャッシュすることができます。 典型的な構成図は以下の通りです。Ansible GalaxyやRed Hat Automation Hubが提供する最新のCollectionsを、インターネットへの接続性を持たないAnsible Towerから利用したいというユースケースがこれにあたります。 ┌─────────────┐ ┌──────────────────────┐ ┌──────────────────────┐ │Ansible Tower├────────────┤Private Automation Hub├──────The Internet───────┤Ansible Galaxy │ └──────┬──────┘ └──────────────────────┘ │ └──────────────────────┘ │ │ │ │ ┌──────────────────────┐ │ └────────────┤Red Hat Automation Hub│ │ └──────────────────────┘ ┌──────┴──────┐ │Managed Node │ └─────────────┘ Private Automation Hubは、AAP1.2から提供されていましたが、プライベートリポジトリとして管理できるコンテンツがCollectionsのみに限定されていました。AAP2.0ではコンテナイメージも管理できるよう、プライベートコンテナレジストリ機能が追加されています。この機能拡張は、次のセクションでご紹介するコンテナベースのジョブ実行環境を提供するのを目的として実装されています。 (注1) アップストリーム版のGalaxyNGの インストール手順 は少々厄介です。インストールパラメータの設定などは、公式サイトの手順記載されているPlaybookを読み解く必要があります。 Container Runtime for Ansible Ansible TowerやAWXのジョブ実行環境(ansible-playbookコマンドの実行環境)は、AAP1.2(Ansible Tower 3.8.z)まではPythonのvirtualenvを利用して構成されていました。 利用者はvirtualenvをカスタマイズすることで、独自のジョブ実行環境を容易に構築することができます。しかしvirtualenvをベースとした実行環境には、PythonインタプリタやPythonモジュール群の互換性、ファイルシステムパーミッション設定など潜在的に問題となる可能性を持つ要因が多くあり、維持管理をする利用者にある程度のPythonの知識があることを前提としていました。 カスタマイズされたvirtualenvを利用した実行環境の運用では、メンテナンス時に誤ってシステムワイドにインストールされたPythonモジュールを上書きしてしまう...といった事故も多く、維持管理をしていくうえで問題が発生するリスクを常に抱えており、より安定した実行環境を求める声が多くありました。 そこで、AAP2.0では、この問題を解決するためのアプローチとしてこの実行環境がコンテナ化されています。コンテナ化された実行環境では、カスタマイズする際の手間こそvirtualenvよりかかりますが、十分にテストされたコンテナイメージの実行環境として提供することで、virtualenvベースの実行環境が持っていた環境の再現性や互換性の問題、カスタム環境をメンテナンスする際のリスクを回避することができ、より安全で安定した実行環境を提供しやすくなります。 一方で、コンテナベースのジョブ実行環境のカスタマイズ作業には、virtualenvのような手軽さは期待できません。そこで、カスタムイメージの作成を支援するためのツールと、その配布を支援するためのシステムをAAP2.0のコンポーネントとして提供することで、このデメリットを小さくするアプローチがとられました。 コンテナベースの実行環境(ベースイメージ) - Red Hat版 / コミュニティ版 カスタムコンテナイメージの作成 - Ansible Builder カスタムコンテナイメージレジストリ - Private Automation Hub コンテナイメージでジョブを実行するためのランチャー - Ansible Runner これらのコンポーネントを利用して、現在のAAP2.0のジョブ実行環境は構成されています。 まとめ こうしてみると、元記事であげた2つのトピックが、現時点で無事にプロダクトレベルでリリースされています。リリースに係わったすべての皆さんに感謝します。ありがとうございました。 AAP2.0 Early Access版のプロダクトアップデートについては、Ansible Automates Japan 2021で講演した際の スライド に、もう少し詳しくまとめてありますので、興味のあるかたは御一読ください。 それではみなさん、12月もHappy Automation :)

Red Hat のソリューションアーキテクトの小杉です。 Red Hat にはクラウドネイティブアプリの開発に役立つ、ソフトウェアのラインナップが充実していることをご存知ですか？ ここでは、それらのソフトウェア [Red Hat Application Services] に関する注目ニュースを、各製品技術に特化したソリューションアーキテクトが、ご紹介します。 今回は 2021/12月号となります。 想定読者 エンタープライズアーキテクト アプリケーション開発者 システムの提案をするSIerの方 特集1: SREのためのMetrics-driven transformation(MDT) その2 前回から時間があいてしまいましたが、「SREのためのMetrics-driven transformation」の続きをお伝えします。今回はダッシュボードアプリのPelorusを実際にデプロイしてみました。 rheb.hatenablog.com 特集2: マイクロサービスを支える Red Hat Integration マイクロサービスの分割方法、分割したサービス同士の連携、API の外部公開を考えていく中で Red Hat Integration がどう役に立つのかをまとめました。ご一読ください。 マイクロサービスと Red Hat Integration from Kenta Kosugi www.slideshare.net 特集3: アプリケーション・モダナイゼーションで有効なソリューション -マイクロサービスアーキテクチャ- マイクロサービスアーキテクチャの考え方の一つを提示してみました。どんなアプリが来ても同じ構成となるので、役割分担が明確化できます。 rheb.hatenablog.com 好評開催中！クラウドネイティブアプリ開発関連のWebinar全６回 Cloud Nativeを見据えたアプリケーションアーキテクチャとレガシーモダナイゼーション コンテナ時代の開発ツールチェインと開発プロセスのベストプラクティス クラウド/コンテナを前提とした時代のアプリケーション実行環境の選択 マイクロサービス/サーバーレス実践入門 これからのシステム連携を実現するデジタル基盤とアプローチ Cloud Nativeなデータパイプラインの作り方とオープンハイブリッドクラウドへの展開 各回とも、オンデマンドで視聴出来ます。（お名前とメールアドレス等の登録のみで視聴可能です） 下記リンクよりぜひご登録ください。 www.redhat.com 直近GAになった製品群 最近リリースとなった Application Services 製品群のリストをご紹介します。 見逃している製品が無いか、是非一度ご確認ください。 Red Hat support for Spring Boot 2.4

みなさんこんにちは、レッドハットでソリューションアーキテクトをしている暮林といいます。 SREのためのMetrics-driven transformation(MDT) というタイトルで数回の連載をしたいと思います。といって結構時間が立ってしまいましたが、今回が二回目です。 前回の記事はこちら rheb.hatenablog.com Pelorusのインストール ワークアラウンドを含めたの今回のインストール手順 helm chartの修正 OperatorのDeploy PelorusのDeploy ダッシュボードを見てみる 次回 Pelorusのインストール OpenShiftを用意して下記の手順の通りやれば動きます！というはずがなかなか苦戦してしまったのでワークアラウンドが必要でした。 （なので今回はインストールまでとなります） pelorus.readthedocs.io 必須条件は下記のようになっています。OpenShift4.9でも動きましたが、Grafana Operator周りで多少の小細工が必要です。 An OpenShift 3.11 or higher Environment A machine from which to run the install (usually your laptop) The OpenShift Command Line Tool (oc) Helm3 jq git 元の手順は下記のとおりですがPythonバージョン周りで問題が解決していないため、今回はMasterブランチを利用します。 # clone the repo (you can use a different release or clone from master if you wish) git clone --depth 1 --branch v1.3.0 https://github.com/konveyor/pelorus cd pelorus oc create namespace pelorus helm install operators charts/operators --namespace pelorus # Verify the operators are completely installed before installing the pelorus helm chart helm install pelorus charts/pelorus --namespace pelorus ワークアラウンドを含めたの今回のインストール手順 helm chartの修正 まずGrafana OperatorとPrometheus Operatorを最新バージョン指定に変えてしまいます git clone https://github.com/konveyor/pelorus.git まず編集すべき箇所は, pelorus/charts/operators/templates/ の下の grafana-subscription.yaml と prometheus-subscription.yaml です。 それぞれを下記のように編集してください。 grafana-subscription.yaml (channelとstartingCSV) --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: grafana-operator spec: channel: v4 installPlanApproval: Manual name: grafana-operator source: community-operators sourceNamespace: openshift-marketplace startingCSV: grafana-operator.v4.0.1 prometheus-subscription.yaml (startingCSV) --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: prometheus spec: channel: beta installPlanApproval: Manual name: prometheus source: community-operators sourceNamespace: openshift-marketplace startingCSV: prometheusoperator.0.47.0 次にGrafanaDashBoardのyamlを微修正します。場所は pelorus/charts/pelorus/templates/ で、dashboard-sdp.yaml と dashboard-sdp-byapp.yamlの2つです。それぞれspecの下のname要素を削除してください。 編集前 spec: name: devops.json json: >- 編集前 spec: json: >- これであとはchartをDeployするだけです。 OperatorのDeploy cd pelorus oc create namespace pelorus helm install operators charts/operators --namespace pelorus 成功すれば下記のようにOperatorが2つDeployされます。(ワークアラウンドをしていないと、指定したOperatorが導入できずに失敗します） PelorusのDeploy helm install pelorus charts/pelorus --namespace pelorus ダッシュボードを見てみる grafana-deploymentの右上にあるリンクをたどると、ダッシュボードが表示されます。 途中でOpenShiftの認証や、oauthの権限承認があります。 Grafanaのトップ画面からHomeを押すとダッシュボード一覧が見えます。 Pelorus→Software Delivery Performanceとたどればこのようにお目当てのダッシュボードが見えました！ 次回 今度こそDemoアプリをDeploy、変更を行うことでダッシュボードにどのような変化がみえるのかをお伝えしたいと思います！ その後はエンタープライズ世界でどうこのダッシュボードと付き合うのがよさそうか、についての考察をしていきたいと考えています。

こんにちは、Red Hatソリューションアーキテクトの石川です。 今月の11月2日にアップストリームのKnativeがバージョン1.0としてリリースされました。 プロジェクトがスタートしたのが2018年とのことなので3年の月日を経て満を辞してのリリースだったかなと思います。 https://knative.dev/blog/articles/knative-1.0/ OpenShiftでもKnativeはOpenShift Serverlessというコンポーネントで提供されており、これを使うことでOpenShiftクラスタ上でサーバーレスのアプリケーションを動かすことが出来ます。 （Knative 1.0対応はまだしてないですが…） 今回の記事ではこのKnativeについてあらためてご紹介していきたいと思います。 ちなみに以前にも赤帽ブログでKnativeについて紹介している記事がありますのでそちらも併せてご参照下さい。 rheb.hatenablog.com rheb.hatenablog.com Knativeの概要 Knativeはサーバーレスでのアプリケーション実行を可能とするOSSのプロジェクトであり、大きくKnative ServingとKnative Eventingという二つの要素で構成されています。 Knative Servingはサーバーレスアプリケーションを公開し、実行する部分を担っており、Knative Eventingは様々なイベント情報とKnative Servingを結びつけ、イベントドリブンなアプリケーション実行を行う役割を持っています。 ちなみに以前はKnative Buildというコンポーネントもあったのですが、そちらはKnativeからスピンアウトしてCIを行うTekton Projectとして独立しました。 一度に全てを説明すると長くなるため今回はこのKnative Servingに焦点を当ててご紹介しようと思います。 Knative Servingは何をしてくれるのか？ さてサーバーレスでのアプリケーション実行ということですがKnative Servingは実際には何をしているのでしょうか。 実はアプリケーションの実行自体は、KubernetesやOpenShiftで普通にアプリケーションを動かすのと同様にPod（コンテナ）で実行しています。 しかしKnative Servingの場合、アプリを実行していないときにこのPodは0までスケールインして完全に停止します。そしてアプリケーションのエンドポイントにアクセスがあったときに初めてPodを起動し、必要な処理を実施し、それが終わればまた停止するというサイクルを繰り返します。 つまり動いてない時はサーバーのリソースが不要（サーバーレス）ということですね。 またKnative Servingのもう一つの特徴として、スケールインだけではなくスケールアウトも出来るという点があります。アプリケーションに対する接続要求が増えれば必要な数だけ自動でPodの数を増やし処理を実行してくれます。 Knative Servingを使わない場合でもPodのスケールアウトは可能ですが、その場合HPA（Horizontal Pod Autoscaler）の設定が必要となるため、Knative Servingの方が楽に実装出来ると言えるでしょう。（HPAとスケールアウトの挙動は異なりますが。） Knative Servingを使用するにはどうすれば良いのか？ Knative Servingを使用するにはKnativeの"Service"と呼ばれるカスタムリソースを作成する必要があります。 Kubernetesのデフォルトのリソースにもネットワーク機能を提供するServiceリソースがありますが、それとこのKnativeの"Service"は別物です。 これ以外にもKnativeにはまぎらわしい名前のリソースが多数存在するため、本記事上ではKnative/ServiceやDefault/Serviceなど区別を付け記述したいと思います。 Knative/Serviceが作成されると、OpenShiftのデフォルトのリソースとKnativeのカスタムリソースをクラスタ上に自動で作成します。 デフォルトリソース ・Deployment：Podのデプロイ ・Default/Service：Podへのアクセス ・Default/Route：クラスタ外部へのアプリケーションの公開 カスタムリソース ・Revision ・Configuration ・Knative/Route 実はこれ以外にも作成されるリソースはあるのですが、まずは一旦これらについて見ていきましょう。 1のデフォルトリソースについてはDeployment、Default/Service、Default/Routeの3種類となります。OpenShiftやKubernetesの経験がある方であれば、これらが作成されることでアプリケーションコンテナがクラスタにデプロイされ、外部公開されるイメージはなんとなく付くのではないでしょうか。 Knative/Serviceを一つ作成するだけでこれらのリソースは自動で作られるため、例えばKubernetesの仕組みに詳しくないアプリケーションの開発者であっても簡単にクラスタ上でアプリを動かすことが出来ます。 2のカスタムリソースについて、 Knative Servingのドキュメント にはそれぞれの関係性を表す以下の図が載っています。 まずKnative/Serviceの情報を元にConfigurationとKnative/Routeという二つのリソースが作成されます。 Knative ServingにおいてデプロイするアプリのバージョンはRevisionという単位で管理されるのですが、ConfigurationがRevisionを作成するためのテンプレート情報を保持しており、それを元にRevisionが作成されます。作成されたRevisionはImmutable（後から変更不可）な性質を持ち、新しいバージョンのアプリがデプロイされると、過去のRevisionの更新を行うのではなく、新たな別のRevisionが作成されることとなります。 Knative/RouteはこれらRevisionに対するトラフィックの振り分け情報を保持しています。デフォルトでは最新のRevisionに100%のトラフィックが振り分けられますが、例えばA/Bテストやカナリアリリースを実施したい場合などに、以前のRevisionと最新のRevisionで9:1などの割合でトラフィックを振り分けることが可能になっています。 このように様々なカスタムリソースが存在していますが、Knative Servingを使用する場合、あくまでこれらは裏側の仕組みであり、利用者の目線では基本的にKnative/Serviceのみを意識すればよく、こちらに対して追加や変更を実施していくこととなります。 Knative/Serviceの作成方法 Knative/Serviceリソースを作成するには大きく以下の3つの方法が考えられます。それぞれ順番に見ていきましょう。 1. yamlを作成しapplyする 2. kn CLIを使用して作成する 3. OpenShiftコンソールから作成する yamlを作成しapplyする Knative/Serviceはカスタムリソースの一種であるため、デフォルトのリソースと同様にマニフェストファイルを作成し、それをapplyすることでクラスタにデプロイすることが出来ます。 apiVersion: serving.knative.dev/v1 kind: Service metadata: name: helloworld-go namespace: default spec: template: spec: containers: - image: gcr.io/knative-samples/helloworld-go env: - name: TARGET value: "Go Sample v1" apiVersion が serving.knative.dev/v1 となっていることに注意しましょう。 このマニフェストでは実行するアプリケーションのコンテナイメージと変数を設定しています。 oc apply -f にて準備したマニフェストを適用するとアプリケーションのエンドポイントが作成されます。そちらにアクセスすると変数で設定された値を含むレスポンスが確認することが出来ます。 curl http://helloworld-go-default.apps.mycluster4.bsf7.p1.openshiftapps.com Hello Go Sample v1! レスポンス返却時にはコンテナが起動していますが、追加のリクエストが無ければ約90秒ほどで停止します。 oc get pod -w NAME READY STATUS RESTARTS AGE helloworld-go-00001-deployment-96bbf98f9-d4m4p 2/2 Running 0 14s helloworld-go-00001-deployment-96bbf98f9-d4m4p 2/2 Terminating 0 63s helloworld-go-00001-deployment-96bbf98f9-d4m4p 0/2 Terminating 0 94s helloworld-go-00001-deployment-96bbf98f9-d4m4p 0/2 Terminating 0 95s helloworld-go-00001-deployment-96bbf98f9-d4m4p 0/2 Terminating 0 95s kn CLIを使用して作成する KnativeにはknというCLIツールがあり、それを使うことでKnative/Serviceを作成することが出来ます。 CLIのインストール方法については Knativeのドキュメント をご参照下さい。 knを使ってyamlを書くパターンと同じ設定のKnative/Serviceを作成する場合は以下のコマンドとなります。 kn service create helloworld-go --env TARGET="Go Sample v1" --image gcr.io/knative-samples/helloworld-go 実行結果としては以下が返却され、最後の行でアプリケーションのエンドポイントが表示されているのが見えます。 （アクセス時の結果は一つ目のパターンと同じため割愛） Creating service 'helloworld-go' in namespace 'default': 0.046s The Route is still working to reflect the latest desired specification. 0.049s Configuration "helloworld-go" is waiting for a Revision to become ready. 0.067s ... 4.996s ... 5.026s Ingress has not yet been reconciled. 5.117s Waiting for load balancer to be ready 5.298s Ready to serve. Service 'helloworld-go' created to latest revision 'helloworld-go-00001' is available at URL: http://helloworld-go-default.apps.mycluster4.bsf7.p1.openshiftapps.com OpenShiftコンソールから作成する これまでの方法はあらかじめアプリケーションのコンテナが準備されていることが前提となっていましたが、OpenShiftコンソールを使うとアプリのソースコードがあればKnative/Serviceを作成することが出来ます。 まずOpenShiftのDeveloperパースペクティブを開き、"+追加"をクリックします。 ここでGitリポジトリを選択し、次の画面に移ります。 デプロイするアプリケーションのソースコードが置かれたGitリポジトリのURLを入力すると、リソースタイプとしてServerlessデプロイメントを選択することが出来ます。このオプションはOpenShift ServerlessのOperatorをインストールしている時のみ表示されます。 Serverlessを選択しアプリケーションを作成すると、トポロジービューからKnative/Serviceが作成され、アクセスのためのエンドポイントが提供されていることが確認出来ます。 このようにOpenShiftコンソールを使うパターンではより簡単にサーバーレスのアプリケーションを実行することが出来ます。 まとめ 今回の記事ではKnative Servingの基礎的な内容についてご紹介させて頂きました。 サーバーレスというと敷居が高いと感じられる方もいらっしゃるかもしれませんが、実際にはわずかなステップで簡単にアプリケーションをデプロイすることが出来ます。 もし自分でも触ってみたいという方がいれば、learn.openshift.comにある Serverlessのコンテンツ を無料で触ることも出来るため是非試してみて下さい！

こんにちはー。Solution Architect 北山です。 今年も OpenShift Commons Gathering の季節がやって来ましたねっ!! 今回はこのイベントの見どころについてお伝えしていきます。 イベント概要 事例セッション紹介 金融事例「チャネルシステムの高速開発を支えるプラットフォーム」 通信事例「大規模レガシーシステムのクラウドネイティブ化への挑戦」 Red Hatセッション OpenShift Managed Practice Partner (OMPP) と語るマネージドサービスの広がりと今後の展望 What's the deal with Managed Services & Model Delivery 終わりに OpenShift Commons Gathering イベント概要 OpenShift Commons Gatheringは、OpenShiftのユーザー、パートナー、技術者などが集まるOpenShift最大のフェスティバルです。 世界3200社以上のエンタープライズに採用されたOpenShiftの「今」がこのイベントに集約されています。 開催日時 : 2021年12月2日 (木) 開催形式 : オンライン配信 参加費 : 無料 主催 : レッドハット株式会社 対象者 : コンテナ技術を検討するITリーダー / アーキテクト / アプリケーション開発者 / IT運用管理者 OpenShift製品・サービスの販売・導入・運用に関わるパートナー www.redhat.com そして、11月12日(金)までに登録いただいた方の中から抽選で30名様に 『Kubernetes CI/CDパイプラインの実装』 （2021年10月新刊）をプレゼント!! 事例セッション紹介 今回も、コンテナを日本で導入されている最先端のエンタープライズ企業様にご登壇いただいたきます。その中から北山の独断で、今回行われるOpenShift Commonsのオススメセッションについて紹介していきます。 金融事例「チャネルシステムの高速開発を支えるプラットフォーム」 先日行われた Cloud Native Days Tokyo 2021 にもご登壇された、三菱UFJインフォメーションテクノロジー株式会社の千野様をお招きし、銀行システムにおけるコンテナ設計や運用についてお話しいただきます。 金融業界を始めとして、ミッションクリティカルな世界で日々運用を行っている開発/運用エンジニア、リーダーの方は必見のセッションです。 チャネルシステムの高速開発を支えるプラットフォーム 今回お話しいただくシステムは、個人資産管理ツールの「 Mable 」。 このアプリは、個人の銀行口座やクレジットカードの管理をモバイルから安心、かつ簡単に管理できる家計簿アプリです。容易なユーザーインターフェースや顧客体験を重視して開発が行われています。 Mable 参考リンク: 三菱UFJ銀行が「コンテナ開発」を選んだ理由、マネーツリーと見つけた“勝ちパターン”とは ｜FinTech Journal 参考リンク: アプリは「コンテナ納品」で、委託先の開発生産性を高めた三菱UFJ銀行 | 日経クロステック（xTECH） 通信事例「大規模レガシーシステムのクラウドネイティブ化への挑戦」 株式会社NTTドコモ様において、レガシーシステムのクラウドネイティブ化を牽引されている永原様をお招きして、レガシーシステムのコンテナマイグレーションについてお話をお伺いします。 エンタープライズでコンテナに取り組む全ての方が、必ず考える「レガシーシステムの刷新」。コンテナ化して行きたい！という理想とともに出てくる多くの課題をどのように乗り越えてきたのかを、実体験をもとにお話しいただきます。 既存システムのマイグレーションを検討していく運用リーダー必見のセッションです!! 大規模レガシーシステムのクラウドネイティブ化への挑戦 Red Hatセッション Red Hatメンバーがお送りするセッションでは、スペシャリストのテクニカルセッションに加え、今回は対談セッションを設けています。 OpenShift Managed Practice Partner (OMPP) と語るマネージドサービスの広がりと今後の展望 こちらのセッションは2019年に発足した Red Hat OpenShift Managed Practice Program のパートナー様をお呼びして、各社のOpenShiftマネージドサービス運用についてお話しいただきます。各社のOpenShiftマネージドサービスの概要から、OpenShiftを日々運用されている実体験の真相に切り込みます。 これからコンテナ基盤の運用を引き受けられる方、またはマネージドサービス利用と自前運用をお悩みの方必見のセッションです。 OMPP Interviews Red Hat OpenShift Managed Practice Program(OMPP)とは、Red Hat OpenShiftのマネージドサービスを提供するパートナー企業を対象とした支援プログラムで、運用者の育成によって安定したサービス提供とビジネス機会拡大を目指すものです。 ascii.jp What's the deal with Managed Services & Model Delivery OpenShiftも様々なユースケースで利用されていますが、その一つとして注目されている機械学習モデルの管理です。本セッションでは Red Hat OpenShift Data Science を活用した機械学習パイプラインの構築について紹介します。 機械学習開発のモデルデータの管理やパラメーターチューニングに苦労されている開発者様必見のセッションです。 What's the deal with Managed Services & Model Delivery OpenShift Data Scienceは、データサイエンティストが機械学習モデルを開発、トレーニング、テスト、デプロイするための環境を簡単に構築できます。Open DataHubに基づき、TensorFlowやPyTorchなどの機械学習用のフレームワークやJupyter Notebookを提供しています。また、NVIDIA GPU Accelerationによって、機械学習パフォーマンスをあげて繰り返し学習モデルの精度を高めます。 OpenShift Data Science 終わりに OpenShift Commons Gatheringはもともとグローバルで展開されており、KubeConの前日とかに行われています。昨年から日本でも展開されるようになり、OpenShiftを活用いただく数多くの方にご参加いただきました。 thinkit.co.jp 今年はそれを上回るコンテンツ盛りだくさんで準備しています。 コンテナ市場の先端を走る OpenShiftの「今」 を是非ご堪能ください!!

こんにちは。Chief Technologistの梅野です。 今日はアプリケーション・モダナイゼーションで提供しているアーキテクチャや方法論について書いてみます。 世間では色々な種類のモダナイゼーションが叫ばれていますが、レッドハットが提唱しているものはちょっとユニークかもしれません。 アプリケーション・アーキテクチャ アプリケーションモダナイゼーションでのアーキテクチャは？と言ったら、皆様すぐに思いつくのはマイクロサービスアーキテクチャではないでしょうか。ところが、このマイクロサービスアーキテクチャについてお客様にお伺いすると、結構バラバラのご意見を伺います。 既存の業務アプリでのユースケースに沿った、画面・ロジック・データが一体化したアプリの粒度　（分けることが出来ない） サーバレス技術を使った、関数レベルのサービス提供 マイクロサービス　を考える前に、まずはマイクロではないサービスを考える必要があります。 まず、皆様の会話の中で「サービス」のことを「一連の業務を支援するアプリ」捉えられているケースがあります。確かに業務視点でみると、それを「サービス」と呼んでいるかもしれません。ですが、この観点だけで「サービス」を定義してよいのでしょうか。 レッドハットでは、「ITとしてのサービス」をまず最初に定義しましょうと提唱しています。ITとしてのサービスとは、下記のようなものです。 次に、このITとしてのサービスを横軸として、縦軸に業務を刺してみます。 そうすると、ITとしてのサービスと業務が交わったところ、ここを黄色の点線で囲ってみます。 この、黄色の点線を「マイクロサービス」として考えてみるのはいかがでしょうか。全てのアプリケーションは同じITとしてのサービスで構成が可能です。いくつかの業務では、例えばUIサービスが無いものもあるかもしれませんが、それはたまたま無いだけで、全てのアプリケーションが同じアーキテクチャで構成できるというのは理想のはずです。「フレームワーク」というのが実装面での共通設計であるように、アーキテクチャとして共通設計できることは、見通しが良くなるものです。 各ITとしてのサービスをレッドハット社の製品に当てはめるとこのようになります（UIだけ、リッチなものがないですが...） ここで、先程のご意見にあった 既存の業務アプリでのユースケースに沿った、画面・ロジック・データが一体化したアプリの粒度　（分けることが出来ない） サーバレス技術を使った、関数レベルのサービス提供 ですが、 1.はモノリスアプリがスライスされるだけなので、あまり効果は見込めません。むしろ、切ってはいけないところで切ってしまいうと、より複雑性が生まれてしまいます。アプリの中で画面・ロジックとデータは一体型にせずに分けるべきと思います。 2.はマイクロサービスと言う概念とサーバレスという実行技術を混同されているものと思われます。あくまでもアーキテクチャとしてのマイクロサービス、実行体としてのサーバレス（サーバー上で常駐起動させていなくとも瞬時に呼び出せる技術で、リソースの省力化などを目指す技術）は別物であると認識いただくべきです。 他のソリューション アプリケーションモダナイゼーションでは、マイクロサービスアーキテクチャ以外にも下記のようなアーキテクチャや考え方を適用すると、より効果的になります。 脱バッチソリューション（イベントドリブンアーキテクチャ） ルール駆動開発手法　（過去に何回か赤帽エンジニアブログでも紹介しております！） rheb.hatenablog.com 適切なツールを使ったデータの移行 現新比較を繰り返すテスト方法と進捗率の確認 コンテナプラットフォームを利用したBlue Greenデプロイメント 次回以降、このあたりもご紹介していきたいと思います。 うめの

森若です。 2021年11月4日Red Hat Enterprise Linux 9.0 Betaが出たので情報まとめです。 RHEL 8と同じく、以下4種類のアーキテクチャに対応しています。 Intel/AMD64 (x86_64) ARM 64-bit (aarch64) IBM Power LE (ppc64le) IBM Z (s390x) 公式のアナウンスはこちらです。 www.redhat.com 主な特徴 RHEL 8.5 betaと比較すると、以下が大きな違いでしょうか。 OpenSSL 3が使われている cgroup v2がデフォルト LTO(Link TIme Optimization)が有効 Python 3.9 SSHでrootユーザに対してパスワード認証が不可になっている (従来もdeprecatedだった)network-scriptsが削除 もちろんその他のデスクトップや言語処理系なども最新に近いバージョンへアップデートされています。 CentOS Stream RHEL 9 は CentOS Streamをベースとして開発される初のバージョンです。 Beta出荷以降の最新の状況を知りたい場合はCentOS Stream 9を見ることができます。 www.centos.org 関連リンク リリースノート: ダウンロード: ダウンロードにはサブスクリプションを持っているRed Hat IDが必要です。 Red Hat Developer Programでの無償サブスクリプション でも大丈夫です。 RHEL 9.0 Betaの不具合などについてのフィードバックはカスタマーサポートまでお寄せください。

レッドハットの杉村です。Ansible のテクニカルサポートをしています。毎月1つは何か書くことを目標にしています。 今月は execution environments について紹介します。 Ansible は Python で書かれており、Python の実行環境を作ってライブラリやモジュールの依存関係を閉じ込めて実行するようになっています。 旧 Ansible Tower では virtual environment の仕組みを使っていました。以前記事を書きましたのでご覧ください。 rheb.hatenablog.com rheb.hatenablog.com Ansible automation controller (旧称 Ansible Tower) では、virtual environment は controller の Web UI やサービスなどを動作するためだけに使われるようになり、ansible-playbook などのコマンドは execution environments という別な仕組みを使うようになりました。 execution environments はこのような特徴を備えています。 Red Hat Enterprise Linux UBI 8 をベースとするコンテナイメージ Ansible 2.9 もしくは Ansible Core 2.11 を動作させることができる Python 3.8 Collections をあらかじめインストールする Python の依存ライブラリや動作に必要な設定ファイルなどもあらかじめインストールできる 実行環境がコンテナとしてまとめられたことにより、Podman のコンテナとして扱えるようになります。イメージ配布の仕組みも新しく Automation Hub に取り入れられ、クラスタとして複数台の controller を使う場合でも、それぞれに virtual environment を作らなくてもよくなっています。 execution environments の作り方 Ansible Automation Platform 2.0.x をインストールしますと、いくつかの execution environments が初期インストールされます。 ansible-automation-platform-20-early-access/ee-supported-rhel8 ansible-automation-platform-20-early-access/ee-minimal-rhel8 こちらの Container images のサイトから検索して見つけることもできますが、単独で取って来て利用いただくことはお勧めしません。 catalog.redhat.com 以前 virtual environment で利用されていたように自分でカスタマイズして使いたいときには、ansible-builder が用意されています。英語ではありますがこちらにドキュメントを書きましたので、弊社のアカウントがある方はご覧ください。 access.redhat.com 例えばコミュニティで開発されているコレクションを使いたいときには必要になると思います。プロジェクトの中で collections/requirements.yml を置くことで、プロジェクトを同期するときにコレクションも動的にダウンロードしてくるという機能があることは先月解説しましたが、そのコレクションが Python のモジュールに依存していて追加で実行環境にインストールしておかなければいけないときには、この requirements.yml では対応できないという問題がありました。 rheb.hatenablog.com 他にも上のドキュメントの例にも書きましたが、Windows を操作するために Kerberos 認証が必要となって /etc/krb5.conf の設定や暗号化周りの設定をカスタマイズしなければいけない場合には、やはり execution environments を作っていただくことになります。 execution environments の使い方 controller の Web UI からは、「実行環境」に登録すればプロジェクトやジョブテンプレート、インベントリー同期などで使えます。 コマンドラインからは、ansible-navigator を通して使うことができます。ansible-builder と同様に、ansible-automation-platform-2.0-early-access-for-rhel-8-x86_64-rpms のリポジトリから dnf でインストールできます。 # dnf install ansible-navigator controller 上で起動させる場合には、awx ユーザでお使いいただくと便利です。たとえばわたしの環境ではこのようにイメージがあります。 # su - awx $ podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/ee-supported-rc4-with-collections latest 6b024619c7ea 13 days ago 1.24 GB localhost/latest_aws_collection_execution_environment_minimal latest 808626f78226 2 weeks ago 400 MB registry.redhat.io/ansible-automation-platform-20-early-access/ee-supported-rhel8 2.0.0 85ca2003a842 2 months ago 920 MB registry.redhat.io/ansible-automation-platform-20-early-access/ee-minimal-rhel8 2.0.0 078c7d4aca51 2 months ago 288 MB registry.redhat.io/ansible-automation-platform-20-early-access/ansible-builder-rhel8 2.0.0 df5d9fdcdbd4 2 months ago 359 MB ansible-navigator からも見ることができます。ansible-navigator images コマンドを実行すると、昔を思い出すようなキャラクタベースのアプリケーションが起動します。数字を押していろいろたどってみてください。 もちろん Ansible のコマンドを実行することもできます。inventory と playbook.yml を用意して、ee を指定して起動した例です。 $ ansible-navigator run playbook.yml -i inventory --eei registry.redhat.io/ansible-automation-platform-20-early-access/ee-supported-rhel8:2.0.0 全体の実行結果が表示されて、数字を押すことで中を掘って見ていくことができます。 従来のような出力で実行させることもできます。 $ ansible-navigator run playbook.yml -i inventory --eei registry.redhat.io/ansible-automation-platform-20-early-access/ee-supported-rhel8:2.0.0 -m stdout PLAY [servers] ***************************************************************** TASK [Gathering Facts] ********************************************************* ok: [192.168.0.100] ok: [192.168.0.101] ok: [192.168.0.102] TASK [ping] ******************************************************************** ok: [192.168.0.102] ok: [192.168.0.101] ok: [192.168.0.100] PLAY RECAP ********************************************************************* 192.168.0.100 : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 192.168.0.101 : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 192.168.0.102 : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 $ プレイブックを実行するだけだとあまり便利になったような気はしませんが、他にもいろいろと機能はありますので、ご興味ありましたらお手元でも動かしてみてください。ドキュメントはこちらです。 access.redhat.com おまけ 実際には podman コマンドから実行してしまうこともよくあります。 $ podman run -it registry.redhat.io/ansible-automation-platform-20-early-access/ee-supported-rhel8:2.0.0 ansible --version ansible [core 2.11.2] config file = /etc/ansible/ansible.cfg configured module search path = ['/home/runner/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules'] ansible python module location = /usr/lib/python3.8/site-packages/ansible ansible collection location = /home/runner/.ansible/collections:/usr/share/ansible/collections executable location = /usr/bin/ansible python version = 3.8.6 (default, Jan 22 2021, 11:41:28) [GCC 8.4.1 20200928 (Red Hat 8.4.1-1)] jinja version = 2.10.3 libyaml = True $ podman run -it registry.redhat.io/ansible-automation-platform-20-early-access/ee-supported-rhel8:2.0.0 ansible-galaxy collection list # /usr/share/ansible/collections/ansible_collections Collection Version ------------------------ ------- amazon.aws 1.5.0 ansible.controller 4.0.0 ansible.netcommon 2.2.0 ansible.network 1.0.1 ... 外からファイルを与えないといけない場合にはコンテナの性質上そのままでは動作しませんので、ansible-navigator コマンドを使うこともあります。controller の Web UI からプロジェクトやジョブテンプレートを作って実行するのが一番楽だとは思います。 おわりに Ansible Automation Platform 2.0 で導入された実行環境 (execution environments) について紹介してみました。 コンテナの扱いはもういまとなっては常識になってきているところがあると思いますし、広く普及したコンテナの知識を Ansible Automation Platform でもご利用いただけるのはとても大きいと思います。 Ansible Automation Platform は Developer Subscription でもお試しいただけますので、ご興味持たれましたら試してみてください。 rheb.hatenablog.com Happy Automation!

Red Hatのソリューションアーキテクトの森です。 Red Hat にはクラウドネイティブアプリの開発に役立つ、ソフトウェアのラインナップが充実していることをご存知ですか？ ここでは、それらのソフトウェア [Red Hat Application Services] に関する注目ニュースを、各製品技術に特化したソリューションアーキテクトが、ご紹介します。 今回は 2021/11月号となります。 想定読者 エンタープライズアーキテクト アプリケーション開発者 システムの提案をするSIerの方 特集1: Keycloak Metrics SPIで、Red Hat SSOの稼働統計をGrafanaで見る Red Hat SSOは、OSSのKeycloakをベースとしたシングルサインオン製品です。シングルサインオン製品を運用する中で、アプリケーション毎のログイン数などの稼働統計などが欲しくなってきます。 今回は、コミュニティのAerogear Keycloak Metrics SPIを使い、Prometheus経由で、GrafanaのKeycloak Metrics用ダッシュボードで確認する方法を紹介しています。 qiita.com 特集2: インテグレーションをサーバーレスで実現するCamel Kの概要をご紹介 Red Hat FuseのアップストリームプロジェクトであるApache Camelのサブプロジェクトとして、Camel Kの開発が進められており、Red Hat Integrationの製品機能としてもGAされました。このCamel Kを使うことで、システム連携を従来のような重厚長大なプロジェクトではなく、クラウドネイティブに行うことができ、マイクロサービスやサーバーレスで実現することができるようになります。このスライドではそのCamel Kの概要について紹介しています。 speakerdeck.com 特集3: Kogito-Onlineでお手軽デシジョンサービス開発 Red Hat Decision Manager は、v7.11より Kogito の一部機能が製品として正式にサポートされるようになりました。 Kogito とは、クラウドに最適化されたビジネスアプリケーションを構築するための技術で、業務ルールをマイクロサービスとして開発をすることが今までよりもお手軽にできるようになります。 今回は、 Kogito Online Editor を使って、意思決定の機能をマイクロサービスとして OpenShift へデプロイしてみようと思います。 rheb.hatenablog.com 好評開催中！クラウドネイティブアプリ開発関連のWebinar全６回 Cloud Nativeを見据えたアプリケーションアーキテクチャとレガシーモダナイゼーション コンテナ時代の開発ツールチェインと開発プロセスのベストプラクティス クラウド/コンテナを前提とした時代のアプリケーション実行環境の選択 マイクロサービス/サーバーレス実践入門 これからのシステム連携を実現するデジタル基盤とアプローチ Cloud Nativeなデータパイプラインの作り方とオープンハイブリッドクラウドへの展開 各回とも、オンデマンドで視聴出来ます。（お名前とメールアドレス等の登録のみで視聴可能です） 下記リンクよりぜひご登録ください。 www.redhat.com 直近GAになった製品群 最近リリースとなった Application Services 製品群のリストをご紹介します。 見逃している製品が無いか、是非一度ご確認ください。 Red Hat build of Quarkus 2.2 Red Hat Single Sign-On 7.5 Red Hat Quay 3.6 Red Hat 3scale API Management 2.11

レッドハットのソリューションアーキテクトの森です。 Red Hat Decision Manager は、v7.11より Kogito の一部機能が製品として正式にサポートされるようになりました。 Kogito とは、クラウドに最適化されたビジネスアプリケーションを構築するための技術で、業務ルールをマイクロサービスとして開発をすることが今までよりもお手軽にできるようになります。 今回は、 Kogito Online Editor を使って、意思決定の機能をマイクロサービスとして OpenShift へデプロイしてみようと思います。 Kogito Online Editor とは Webブラウザで DMN、BPMN、PMMLファイルを直接編集することができるオンラインエディタです。 DMNファイルについては、ブラウザ上で入力を与えて、出力の内容の確認を行なったり、OpenShiftと連携してへDMNをデシジョンサービスとしてデプロイを行う、ということが可能になっています。 ※ DMN の入出力の確認、及びOpenShiftへの連携は、別途 KIE Tooling Extended Services のインストールが必要になります。 ※ OpenShiftと連携してのデプロイはお試し版となっております。 事前準備 今回は、あらかじめ用意されているサンプルに少し手を加えたものを使用します。以下のURLをコピーして、 Open from source からファイルを開いていきましょう。 https://gist.github.com/kamorisan/6c911ffd7273ee6951b70c95eb4dc58a 以下のような画面がオープンします。 DMN のサンプルの中身については後程解説をします。先に使用するための事前準備をしていきましょう。 KIE Tooling Extended Services のインストール 上部メニューの Deploy 、もしくは Run をクリックしていくと、 Set up のウィンドウが開きますので、ナビゲーションに従って進めていきます。 インストール後、アプリケーションを実行していきます。上部メニューの Deploy の左のアイコンが、赤から緑に変わっていればOKです。 Run メニューを押すと、DMN検証用の入力・出力のフォームが表示されるようになります。 OpenShift に連携する OpenShiftには、 Developer Sandbox for Red Hat OpenShift という、 セルフサービスで実行する無料のクラウドホスト型のサンドボックスがあり、開発者向けの Red Hat Developer アカウントを取得（無償）すれば、 30日間無料でOpenShiftクラスタを実行できます。今回はこちらを使用していきます。 Red Hat Developer アカウントの取得: 既にお持ちの方は飛ばして次に進んでください。アカウントをお持ちで無い方は、 こちら から登録をしてください。 Developer Sandbox for Red Hat OpenShift の実行 Get started in the Sandbox にアクセスして、 Launch your Developer Sandbox for Red Hat OpenShift をクリックします。 先ほど登録をしたアカウントの情報でログインをした後、SMSによる認証があります。 SMSを受信可能な電話番号を入力して、 Send Code をクリックしてください。 SMSで6桁のコードが送信されますので、入力して Verify Code をクリックします。 Start using your sandbox をクリックして、起動をします。 Kogito Online Editor に OpenShift 認証情報を登録 Developer Sandbox にアクセスできたら、OpenShiftの認証情報を取得して、Kogito Online Editor と連携できるようにします。 OpenShift Web Console の右上のユーザー名をクリックして、 copy login command を選択します。 display token をクリック後、以下のようなログイン情報が表示されますので、真ん中の Log in with this token の、 --token=***** 、 --server=***** の部分をコピーしておきます。 Kogito Online Editor に戻り、上部メニューの Deploy をクリックし、 Setup を選択してください。 Namespace は、ユーザーID＋ -dev 、 Host は先ほどの認証情報の --server= 以降の内容を、 Token は、 --token= 以降の内容を貼り付けます。 入力したら、 Save をクリックしてください。 これで事前準備は完了です！ サンプルの DMN をデプロイしてみる それでは、サンプルの DMN を解説していきます。 今回のサンプルは、住宅ローンの事前審査を自動判定するルールで、 DTI(Debt To Income)、とクレジットの信用スコアを元に判定を行なっています。 DTI とは、住宅ローン債務者の年間返済額の年収に対する比率で、フロントエンド比率、バックエンド比率の2つの指標があります。 * フロントエンド比率: 総住宅費（住宅ローンの毎月の支払額と、住宅にかかる税金や保険料の合計）を収入で割った比率 * バックエンド比率: 総住宅費に加え、クレジットカードや自動車ローンなどの他の種類の債務の合計を収入で割った比率 今回のサンプルルールではフロントエンド比率は28%以下、バックエンド比率は36%以下が望ましいとされています。 クレジットの信用スコアについては、FICOスコアを対象としたものになっています。 FICOスコアは300~850点の間で評価され、 例えば650点以上であれば健全であるとの判断をします。 参考リンク: www.myfico.com DMNのデシジョンノード（長方形）をクリックし、左に表示される 編集 アイコンをクリックすると、設定されている各デシジョンの内容が確認できます。 ・クレジットスコアの判断内容 ・フロントエンド比率の計算 ・バックエンド比率の計算 それでは、実際に入力を与えて動かしてみましょう。上部メニューの Run をクリックし、Inputsフィールドに必要項目を入力していきます。 Credit Score(クレジットスコア): 700 Applicant Data Monthly Income(月の収入): 2000 Repayments(月の総返済額): 450 Expenses(その他経費): 200 Tax(税金): 50 Insurance(保険料): 150 Requested Product Rate(金利): 1.0 Term(返済期間(月)): 120 Amount(ローン金額): 40000 この他の項目は、とりあえずは空欄でも構いません。Outputsフィールドに出力結果が表示されていると思います。 上記の入力であれば、ローンの事前審査結果は Qualified となっていますが、 例えば、 Income の値を 2000 -> 1900 に変更すると、フロントエンド比率の計算が28%を超えてしまうため、 Not Qualified となることが確認できるかと思います。 続いて、Developer Sandbox へのデプロイを実施してみましょう。 上部メニューの Deploy -> Deploy your model -> Confirm をクリックします。 Quarkus 上で動作するアプリケーションとして、Developer Sandbox にデプロイされます。 Developer Sandbox の Web Console を確認してみましょう。 アプリケーションのPodの円の外側の色が濃い青になればデプロイ完了です。 デプロイされたデシジョンサービスは、REST APIで呼び出して実行をすることができます。 Swaggerも内包されていますので、利用可能なAPIを確認してみましょう。 以下のURLにアクセスします。 {Route_URL} の部分は、デプロイされたアプリケーションをクリックし、 Resource タブの下の方にある Routes のURLに差し替えてください。 https://{Route_URL}/q/swagger-ui/ GETメソッドが1つと、POSTメソッドが2つあります。GETメソッドは、DMNの中身をXML形式で取得するものです。POSTメソッドはデシジョンの評価を行うものですが、末尾に /dmnresult ものは、通常の出力に加えて、各デシジョンが正常に実行されたかどうか、またエラーが発生した場合はその内容も合わせて出力されるようです。 POSTメソッドの /loan-pre-qualification から実行してみます。 入力をjson形式で設定しますが、必要な項目の雛形を作成してくれているので、中身の値を変えて実行しましょう。 先ほど確認で使用した値を入れてみます。 以下をコピーして貼り付けて実行頂いてもOKです。 { "Credit Score": { "FICO": 700 }, "Applicant Data": { "Age": 30, "Marital Status": "M", "Employment Status": "Employed", "Existing Customer": true, "Monthly": { "Income": 2000, "Repayments": 450, "Expenses": 200, "Tax": 100, "Insurance": 100 } }, "Requested Product": { "Type": "Standard Loan", "Rate": 1, "Term": 120, "Amount": 40000 } } 実行すると、以下のような出力が返ってくると思います。 { "Requested Product": { "Type": "Standard Loan", "Rate": 1, "Amount": 40000, "Term": 120 }, "Lender Acceptable PITI": "function Lender Acceptable PITI( )", "Credit Score Rating": "Good", "Back End Ratio": { "Ratio": 0.325, "Result": "Sufficient" }, "Lender Acceptable DTI": "function Lender Acceptable DTI( )", "DTI": "function DTI( d, i )", "Applicant Data": { "Monthly": { "Repayments": 450, "Expenses": 200, "Insurance": 100, "Income": 2000, "Tax": 100 }, "Employment Status": "Employed", "Marital Status": "M", "Existing Customer": true, "Age": 30 }, "Front End Ratio": { "Ratio": 0.2752082427403056, "Result": "Sufficient" }, "Loan Pre-Qualification": { "Qualification": "Qualified", "Reason": "The borrower has been successfully prequalified for the requested loan." }, "PITI": "function PITI( pmt, tax, insurance, income )", "Credit Score": { "FICO": 700 } } まとめ いかがでしたでしょうか？ Kogito の登場により、業務ロジックをQuarkus上での軽量なデシジョンサービスとして運用することが可能になるなど、今まで以上にマイクロサービス開発が手軽にできるようになってきています。 Kogito のより詳しい情報については、こちらのドキュメントも参考にしてみてください。 docs.jboss.org また、Kogito Online Editor から Developer Sandbox for Red Hat OpenShift へのデシジョンサービスのデプロイについてはお試し版となっております。 現在は以下の制限がありますので、注意してください。 Developer Sandbox for Red Hat OpenShift との連携について、認証情報のトークンは毎日更新する必要があります。 デプロイしたアプリケーションの変更はできません。（修正した場合は新規にデプロイをする必要があります） デプロイできるアプリケーションの数の上限は10です。 デプロイしたアプリケーションは8時間後にダウンします。（手動での再起動は可能です）

アプリケーション・モダナイゼーションを検討されている方々に是非検討いただきたいのが、レッドハットが提唱している「ルール駆動開発」です。 ユーザーインターフェース、プロセス、ディシジョン、データ、インテグレーション等といったITとしてのサービスと、業務と言うドメインが交わる一つ一つをマイクロサービスアーキテクチャとし、疎結合で考えていきます。時間を掛けて解析しても全容がわからないようなソースコードから仕様を起こすのではなく、業務部門との距離を縮めて一緒に考え、実データをテストデータとして現新比較を行いながらロジックを詰めていく開発手法です。 さっと読んでご理解いただけるよう、ルール駆動開発のまんがを用意しております。 redhat.lookbookhq.com お名前の記入が必要になりますが、右上のダウンロードボタンよりダウンロードして是非御覧ください！ 実際にこのやり方で遂行いただいたお客様より、続々と嬉しいご報告も頂いております。 プロジェクト進行のお役に立てると確信しております。 SA 梅野

こんにちは、Red Hatのソリューションアーキテクト金森です。 みなさんコンテナ触ってますか？ 私が人生で初めて触ったコンテナは 海上20feetコンテナ でした。 コンテナって借りた時、前の荷主がナマモノとか運んでたりするとコンテナ内が生臭くて困っちゃいますよね。 というわけで、今日はコンテナの話です。 コンテナプラットフォームといいつつ、CI/CDの仕組みもサーバレスやサービスメッシュの仕組みもマネージドサービス的に色んなアプリを使える仕組みなど様々な機能をOSSで実現しているRed Hat OpenShift Container PlatformをAWSさんから提供されるマネージドサービスとして使える ROSA について書いていこうと思います。 タイトルの通り、ROSA (Red Hat OpenShift service On AWS)がどれくらいの費用がかかるのかを実感を持って調べたかったのでやってみました。 デプロイして課金される様子を眺め、その結果から年間でどれくらいかかるかを予測します。 この投稿ではデプロイするまでの流れと、AWSさんから届いた請求額を公開して行こうと思います。 ただしお約束として、ここで書かれる金額はあくまで概算であり精緻さは目指していないことをあらかじめご了承ください。 （参考程度にしてね） 今回は以下のような流れでマルチAZなOpenShiftクラスターを構成していきます。 結果だけをみたい方は結論まで飛ばしてもらって大丈夫です。 デプロイまでのながれ いざデプロイ ROSAデプロイ後の設定や確認 で、いくらかかりました？ 結論。 デプロイまでのながれ 未来のだれかに迷惑をかけたくないので書いておくと、これは2021/9末時点の手順を基にしています。 公式な手順は このあたりを 参考にしてください。 詳細なデプロイ手順は 他のメンバーによるブログ記事でも解説 されております。 ROSAをデプロイするまでの道のりは以下の通りです。 （無い場合）AWSのアカウントを作成し、ROSA用のIAMユーザを作成する。 AWSのマネジメントコンソールでROSAサービスを有効にする （無い場合）AWS-CLIを操作端末へインストールし、awsコマンドが利用できるようにしておく （無い場合）Red Hatアカウントを作成する （無い場合）ROSAコマンドを操作端末へインストールしRed Hatアカウントでログインする AWSの権限とQuotaがROSAのデプロイに問題ないかを確認する いざデプロイ ほとんどが前準備ですね。 AWSを普段利用している人ならAWS CLIは既に手元にあると思うので、ROSA CLIを端末にセットアップして貰えればOKと思います。 繰り返しですが、デプロイ興味ないですという人は結論まで飛ばしてください。 いざデプロイ ではセットアップを始めます。 [rkanamor@rkanamor-pc ~]$ rosa init I: Logged in as 'XXXXXXXXXXXXXXXXXX@redhat.com' on 'https://api.openshift.com' I: Validating AWS credentials... I: AWS credentials are valid! I: Validating SCP policies... I: AWS SCP policies ok I: Validating AWS quota... I: AWS quota ok. If cluster installation fails, validate actual AWS resource usage against https://docs.openshift.com/rosa/rosa_getting_started/rosa-required-aws-service-quotas.html I: Ensuring cluster administrator user 'osdCcsAdmin'... I: Admin user 'osdCcsAdmin' created successfully! I: Validating SCP policies for 'osdCcsAdmin'... I: AWS SCP policies ok I: Validating cluster creation... I: Cluster creation valid I: Verifying whether OpenShift command-line tool is available... I: Current OpenShift Client Version: 4.8.11 あっさり終わりました。 必要なユーザなどが作成され、Quotaチェックなど再度行われたようです。 この先はEC2などが立ち上がるので、いよいよ課金がスタートです。ゴクリ。 僕にとってはじめてのROSAクラスターなのでrk-hajimeteno1にしました。 失敗したらhajimeteno2にしようと思います。 構成は東京リージョンにMulti-AZな構成でデプロイします。 $ rosa create cluster --multi-az --cluster-name=rk-hajimeteno1 I: Creating cluster 'rk-hajimeteno1' I: To view a list of clusters and their status, run 'rosa list clusters' I: Cluster 'rk-hajimeteno1' has been created. I: Once the cluster is installed you will need to add an Identity Provider before you can login into the cluster. See 'rosa create idp --help' for more information. I: To determine when your cluster is Ready, run 'rosa describe cluster -c rk-hajimeteno1'. I: To watch your cluster installation logs, run 'rosa logs install -c rk-hajimeteno1 --watch'. Name: rk-hajimeteno1 ID: XXXXXXXXXXXXXXXXXX External ID: OpenShift Version: Channel Group: stable DNS: rk-hajimeteno1.a2wo.p1.openshiftapps.com AWS Account: XXXXXXXXXXXXXXXXXX API URL: Console URL: Region: ap-northeast-1 Multi-AZ: true Nodes: - Master: 3 - Infra: 3 - Compute: 3 Network: - Service CIDR: 172.30.0.0/16 - Machine CIDR: 10.0.0.0/16 - Pod CIDR: 10.128.0.0/14 - Host Prefix: /23 State: pending (Preparing account) Private: No Created: Sep 22 2021 07:14:17 UTC Details Page: https://console.redhat.com/openshift/details/s/XXXXXXXXXXXXXXXXXX [rkanamor@rkanamor-pc ~]$ 無事にOpenShiftクラスターがawsサービスとしてデプロイされました！ 実際にはこのコマンドが終了しても裏ではクラスターのインストール処理がまだ走っているはずです。 すでにSREが運用監視に入っているらしいので、EC2ノードやELBなどを無邪気に落とすと怒られるらしいです。気になりますね〜。 ROSAデプロイ後の設定や確認 やりたいことはできたのですが、せっかくなのでクラスターにもログインできるようにしました。 今日は手っ取り早くローカルユーザを追加します。 （検証なのでSElinuxをオフくらいの気持ちでやってます。本来はidp設定をしたほうが良いです） [rkanamor@rkanamor-pc ~]$ rosa create admin --cluster=rk-hajimeteno1 W: It is recommended to add an identity provider to login to this cluster. See 'rosa create idp --help' for more information. I: Admin account has been added to cluster 'rk-hajimeteno1'. I: Please securely store this generated password. If you lose this password you can delete and recreate the cluster admin user. I: To login, run the following command: oc login https://api.rk-hajimeteno1.a2wo.p1.openshiftapps.com:6443 --username cluster-admin --password XXXXXXXXXXXXXXXXXX I: It may take up to a minute for the account to become active. 出力をみていたらidpも設定したくなったのでGithubをidpに設定してみます。 [rkanamor@rkanamor-pc ~]$ rosa create idp --cluster=rk-hajimeteno1 --interactive I: Interactive mode enabled. Any optional fields can be left empty and a default will be selected. ? Type of identity provider: github ? Identity provider name: github ? Restrict to members of: organizations ? GitHub organizations: rkanamor-XXXXXXXXXXXXXXXXXX ? To use GitHub as an identity provider, you must first register the application: - Open the following URL: https://github.com/organizations/rkanamor-XXXXXXXXXXXXXXXXXX/settings/applications/new?oauth_application%5Bcallback_url%5D=https%3A%2F%2Foauth-openshift.apps.rk-hajimeteno1.a2wo.p1.openshiftapps.com%2Foauth2callback%2Fgithub&oauth_application%5Bname%5D=rk-hajimeteno1&oauth_application%5Burl%5D=https%3A%2F%2Fconsole-openshift-console.apps.rk-hajimeteno1.a2wo.p1.openshiftapps.com - Click on 'Register application' ? Client ID: XXXXXXXXXXXXXXXXXX ? Client Secret: [? for help] **************************************** ? GitHub Enterprise Hostname (optional): ? Mapping method: claim I: Configuring IDP for cluster 'rk-hajimeteno1' I: Identity Provider 'github' has been created. It will take up to 1 minute for this configuration to be enabled. To add cluster administrators, see 'rosa grant user --help'. To login into the console, open https://console-openshift-console.apps.rk-hajimeteno1.a2wo.p1.openshiftapps.com and click on github. [rkanamor@rkanamor-pc ~]$ Github側の設定もありましたが、とても簡単にできました。 これでGithubアカウントでもOpenShiftにログインできるし友達がいれば一緒に開発できそうですね！ さて。 OpenShiftクラスターにログインしてみます。せっかくローカルユーザ作ったので先ずはローカルユーザで。 $ oc login https://api.rk-hajimeteno1.a2wo.p1.openshiftapps.com:6443 --username cluster-admin --password XXXXXXXXXXXXXXXXXX Login successful. You have access to 89 projects, the list has been suppressed. You can list all projects with 'oc projects' Using project "default". Welcome! See 'oc help' to get started. $ $ oc whoami cluster-admin 問題なさそうです。 ノードがちゃんと実行されてるかを見てみます。 $ oc get nodes NAME STATUS ROLES AGE VERSION ip-10-0-132-170.ap-northeast-1.compute.internal Ready master 57m v1.21.1+9807387 ip-10-0-132-93.ap-northeast-1.compute.internal Ready infra,worker 22m v1.21.1+9807387 ip-10-0-134-150.ap-northeast-1.compute.internal Ready worker 49m v1.21.1+9807387 ip-10-0-172-57.ap-northeast-1.compute.internal Ready worker 50m v1.21.1+9807387 ip-10-0-185-234.ap-northeast-1.compute.internal Ready master 58m v1.21.1+9807387 ip-10-0-190-20.ap-northeast-1.compute.internal Ready infra,worker 22m v1.21.1+9807387 ip-10-0-199-143.ap-northeast-1.compute.internal Ready master 58m v1.21.1+9807387 ip-10-0-199-97.ap-northeast-1.compute.internal Ready worker 50m v1.21.1+9807387 ip-10-0-213-113.ap-northeast-1.compute.internal Ready infra,worker 22m v1.21.1+9807387 $ 無事にMaster3, Infra3, Worker3の合計9Nodeがインストールされ立ち上がっていました。 このあと、GithubアカウントでちゃんとOpenShiftのWebコンソールにログインして、なにかしようかな〜と思ったのですが、今回クラスターをデプロイした理由は「ROSAクラスタのマルチAZデプロイ時にどんなリソースが使われるのかを実際見てみたい」だったことを思い出しました。 つまり僕にはクラスターをデプロイする以外にやりたいことは特に無かったのです。 そのことに気がついて、OpenShiftの開発者画面をそっと閉じました。 くれぐれも皆さんはOpenShiftなどをご利用の際には「なにかをデプロイすることを目的」にすることなく、「なにを実現させたいのか」を考えた上で行動してくださいね。 IPAのDX白書にもそんな文言があったみたい です。 さて。 デプロイは終わったのでこの後1日ほど気絶しました。 で、いくらかかりました？ ここからは結果を見てみましょう。 マネジメントコンソールのbilling画面で丸一日稼働していた結果を抜き出してみました。 $120弱。消費税別っぽい。 EC2と周辺料金で88%くらい、ROSA(Red Hat OpenShift Service on AWS)の料金が10%前後となっています。 今回の算出ではほぼ割引などが無い状況かつマルチAZ構成でおよそ$120かかりました。 一年だと$43,800程度からスタートと言えるかと思います。 （ディスカウントを考慮しませんでしたが、一方で実運用時に発生するアプリケーションのトラフィックや監視のためにCloudWatch利用分、AWSさんのサポート費用も含まれていないことに注意してください。 ） 結論。 Q.マルチAZなROSAクラスタにいくらかかるの？ Ans. 今回は実測一日 $120くらいでした。 一月だと$3,600くらい、一年だと単純に365倍で$43,800くらいかかりそうです。 （あくまで目安です） 前述の補足事項にも注意しながら参考になれば幸いです。 せっかくなので、詳細な請求書もせっかくなので文末に貼っておきます。 （1.5日程度放置していた結果なので、こちらの請求書では$238となっています。） 最後に。 シングルAZ構成と今回のマルチAZ構成の違いは以下のような点が挙げられます。 最小構成のノード数が2ノード違う（Single AZではMaster3, Infra2, Worker2の合計7ノードに対し、Multi AZ構成では3つのAZにMaster, Infra, Workerが1ノードずつすべて3ノードで構成され合計9ノードが最小で必要になります) マルチAZなので、当然AZ間の通信が発生する。何もしてないOpenShiftクラスターでもetcdがAZ間を元気にやりとりしてたと思われる。 構成の違いについては 他のメンバーによるブログ記事でも解説 されておりますのでこちらもご確認ください。 前述のようにEC2の料金が支配的ですので細かく計算する意味はあまりないかもしれませんが、ついでにAZ間通信がどの程度発生したのかを見てみます。 クラスタ削除前に確認したところ、AWSさんの請求書に記載されたAZ間通信はその時点で645GB程度発生していました。 AWSさんからの請求書から切り抜き。 構築時のトラフィックもあるため正確さにかけるかもしれませんが、構築後放置した1日に絞ると約$5の通信料でした。 月額ではおよそ$150程度と言えそうです。 表示を切り替えてZone間通信をハイライトしています いずれにしてもマルチAZを選択したから費用が増えたというよりも、最小構成では必要なEC2が2ノード違うという方が大きな違いと言えそうです。 ROSAを利用することで、AWSの柔軟なリソースとOpenShift上の様々なサービスを利用でき、 Red Hatの深いサポート を得られるということがユーザさんにとっても良い選択肢になるといいなと思っています。 ROSAのデプロイだけでなく、色々なOSSで構成された各種サービスや開発体験を体験頂けると嬉しいです。 その中でもし未知の問題や課題と出会った際には、Red Hatの知見を活用いただき、Red HatがどのようにOSSコミュニティと協働しながらそれらの課題を乗り越えていくのかも観測してもらえると嬉しいです！ 最後に、今回検証した 9月の全ての請求書 をこちらに置いておきます。 デプロイされた期間は全体では2日弱ですので、$238の請求になっています。 何かの参考になれば幸いです。 （おしまい） (ここから宣伝) もっと知りたいんだが？という人はぜひ10/20に開催されるRed Hat Forumへご参加ください。 www.redhat.com 参加するとTシャツやバッグが貰えたり、トレーニングの割引など色々あるみたいですよ・・・！ OpenShiftとkubernetesは何がちがうの？何が含まれてるの？が気になった人はこちらをどうぞ www.redhat.com Red Hatのサポートは何をしてくれるの？が気になった人は こちら とりあえず触りたいんだけど？という人は こちら OpenShiftを使ってみんな何をしているの？なにが変わるの？というひとは こちら OpenShiftの最新アップデート情報はYoutubeでも配信してます www.youtube.com (宣伝おしまい)

OpenStackやOpenShiftなどのCloud製品を担当しているソリューションアーキテクトの輿水です。 宣伝になりますが、10月7日〜8日に「 Containers and Cloud-Native Roadshow 2021 October 」というOpenShiftのワークショップが開催されます。DEV TrackとOPS Trackに分かれており、それぞれソフトウェア開発者向け、運用管理者向けのワークショップとなっております。過去に、運用管理者向けのワークショップの内容を記事にしましたので参考にしてください。 rheb.hatenablog.com rheb.hatenablog.com rheb.hatenablog.com 最近と言うほど最近でもありませんが、Red Hat OpenShift Container Platform（以降OCP）の4.8がリリースされたので、OpenStackに続いて、OCPのライフサイクルについて記載します。 OCPのライフサイクル OCPのアップグレード Red Hat OpenShift Container Platformのライフサイクル OCPはKubernetesプロジェクトと近いサイクルで提供されています。Kubernetesが概ね３ヶ月〜４ヶ月毎なので、それに追従する方針となっています。 OCPのライフサイクルはフルサポートとメンテナンスサポートで構成されます。マイナーバージョンのフルサポート期間は、2つのバージョンで１ヶ月の重複期間があるように設定されています。 フルサポート期間：一般提供日から後続のマイナーバージョンの一般提供日の後１ヶ月（約４ヶ月） メンテナンスサポート期間：フルサポート終了後から後続の３マイナーバージョンの一般提供日（約５ヶ月） 一部のマイナーバージョンでは、フルサポート終了後に14ヶ月のメンテナンスサポートを提供するExtended Update Support （EUS）を提供しており、そのバージョンのサポートはフルサポート期間を合わせて約18ヶ月になります。 現時点でのEUS対象は4.6のみです。プラス14ヶ月の場合、本来は終了が2022年5月になるのですが、後続の OpenShift EUS リリースとの重複期間を延長するために、 OpenShift 4.6 EUS の終了日は 2022年10月27日に延長されています 。なお、次のEUSは4.10が予定されています。（ クラスターの更新-[3.3. OpenShift Container Platform アップグレードチャネルおよびリリース]の[eus-4.6 チャネル] 参照） ▼日時 バージョン 一般提供開始日 フルサポート終了日 メンテナンスサポート終了日 フルサポート中のバージョン 4.8 2021年7月27日 4.9 のリリース + 1ヶ月 4.11 のリリース メンテナンスサポート中のバージョン 4.7 2021年2月24日 2021年8月27日 4.10 のリリース 4.6 EUS 2020年10月27日 2021年3月24日 2022年10月27日 4.6 2020年10月27日 2021年3月24日 4.9 のリリース ライフサイクル終了バージョン 4.5 2020年7月13日 2020年11月27日 2021年7月27日 4.4 2020年5月5日 2020年8月13日 2021年2月24日 ※記載されている将来の日付はすべて概算であり、決定的なものではなく、変更される可能性があります Red Hat OpenShift Container Platformのアップグレード OCPはOTA (over-the-air)updateを提供しています。4.X.y→4.X.zだけでなくマイナーバージョン間のアップデート（4.X→4.Y）もWebコンソールを使用すると数クリックで更新できます。更新される内容は以下になります。 マスターノードのアップデート Kubernetes APIのアップデート（kube-apiserver/etcdなどのコアコンポーネント） クラスタ管理サービスのアップデート（PrometheusやContainer Network InterfaceなどのCluster Operator） ホストOS(CoreOS)のアップデート ワーカーノードのアップデート kubeletやContainer Network Interfaceなどの管理対象コンポーネント ホストOS(CoreOS)のアップデート Webコンソールを使用してのアップデートのイメージです。OCP4では、適切なリリースバージョンを選択できるようにチャネルという概念が導入されています。この例では、現行のバージョンは4.7.31で、アップデートのパスとしては4.7のマイナーバージョンを使い続けるチャネルと4.8にアップデートするチャネルを選択することができます。 なおOCPはKubernetesプロジェクトを追従しており、OCPの各バージョンとベースとなるKubernetesのバージョンの関係は以下のようになっております。 OCPバージョン Kubernetesバージョン フルサポート中のバージョン 4.8 1.21 メンテナンスサポート中のバージョン 4.7 1.20 4.6 EUS 1.19 4.6 1.19 ライフサイクル終了バージョン 4.5 1.18 4.4 1.17 OCPのアップデートは、基本的は4.6→4.7→4.8のようにマイナーバージョンごとにアップデートすることが前提となっております。インフラCI/CDという観点からは適宜最新版にアップデートしていただくことが望ましいのですが、そうは言っても稼働しているプラットフォームを頻繁にアップデートするのは難しいというご意見もあるかと思います。それ故に、長期サポートのEUSが登場しております。 EUSを利用した際に、途中のバージョンを飛ばしてEUS→EUSというアップデートを行いたいという要望もあると思います。現時点で、4.6EUSから4.10EUSへのアップデートにおいて、ワーカーノードに関しては途中のバージョンをスキップしてアップデートを行える仕組みを検討しています。（ビデオの19分〜20分付近で説明） www.youtube.com 最初にご案内したContainers and Cloud-Native Roadshowの内容にはクラスターアップデートの演習は含まれていないのですが、参加者それぞれがOCPのクラスターをひとつ専有してのワークショップなので、アップデートを行うこともできます、ただしアップデートには多少時間がかかるため、余裕があれば、という形になります。もしご興味があればお問い合わせください。

レッドハットの杉村です。Ansible のテクニカルサポートをしています。毎月1つは何か書くことを目標にしています。 今月は Ansible Automation Controller (旧称 Ansible Tower) で扱うプロジェクトについて、特に Git との連携の観点から少々解説しようと思います。今回は Controller 4.0.0 で説明しますが、従来の Ansible Tower 3.8 でも新機能や新画面を除いては同様の動きをします。 docs.ansible.com プロジェクトに含まれるもの プロジェクトは Ansible が実行しようとする処理をまとめたディレクトリやファイルです。例を挙げるとこのような構成になっています。プレイブックやダイナミックインベントリのための定義などが含まれています。 github.com docs.ansible.com Controller のサーバ上では、/var/lib/awx/projects/ ディレクトリ以下に格納されます。プロジェクトはジョブを実行するたびに /tmp ディレクトリにまるごとコピーされ、複数のジョブを起動してもお互いに影響しないようになっています。 この毎回まるごとコピーされる仕様は、ジョブ間のリソースの競合によるロックをできるだけ排除するために Tower 3.6 から導入されました。そのため、プロジェクトのディレクトリは大きくしすぎないようにすることをお勧めします。例えば GBytes の大きさにもなる OS の ISO イメージをプロジェクト内に置いておくというような使い方は避けるようにしてください。 プロジェクトはソースコントロールシステム (SCM) から取得して管理することが想定されています。いくつかの種類に対応しています。 Manual (直接ディレクトリを /var/lib/awx/projects/ 以下に作成して配置) Git Subversion Red Hat Insights ( 先月書いた記事 のものです) Remote Archive (tar.gz や zip にまとめたものを Git などに置いて使う) ここでは、主に Git を使ったプロジェクトについて紹介します。 プロジェクトを使うもの プロジェクトはいくつかの場面で使われます。 ジョブテンプレート これがもっとも一般的な利用方法で、プレイブックを実行するためのものです。プレイブックを1つ以上含むプロジェクトを選択すると、Playbook のフォームのプルダウンから選択できるようになります。 ワークフローテンプレート ワークフローテンプレートは処理をノードとして組み合わせてワークフローを作る機能です。 プロジェクトを同期してジョブテンプレートを実行するというようなものを作ってみますとこのようになります。 ただ、これはいい例ではありません。普通はこのようなワークフローを作らなくても、プロジェクトに設定をすることで、ジョブテンプレートを実行するときにプロジェクトを更新させることができます。ワークフローにするときは例えば間に承認プロセスを挟みたい場合や、複数のジョブテンプレートを組み合わせたい場合などが考えられます。 インベントリーソース プロジェクトはインベントリソースとしても使うことができます。インベントリは Ansible がアクセスする処理対象を設定するものなのですが、動的にクラウドサービスなどから条件を指定して接続先の情報を取得することができます。 こちらのスクリーンショットのようにさまざまなサービスからの取得に対応していますが、プロジェクトの中にインベントリの設定ファイルを置くことで、独自にインベントリプラグインを利用して処理対象を取り出していくことができます。単にインベントリ情報を JSON や INI ファイルで記述したものを Git で管理して、都度更新しながら使うという使い方もできます。 プロジェクトの設定による違い ジョブテンプレートを実行したときには対応するプロジェクトディレクトリが /var/lib/awx/projects/ ディレクトリにすでにあるかどうかを確認し、取得していなかったときには Git から取ってくるという動きをします。 プロジェクトにはオプションがいろいろとあります。 クリーニング 普通の使い方ではここを意識する必要はないのですが、プロジェクトディレクトリに Controller のサーバ内で変更を加えた場合には Git の元のリポジトリと競合する場合がありますので、このオプションを有効にしておくとローカルの変更を戻してから同期処理を進めるようになります。 削除 プロジェクトディレクトリを完全に削除してから再度全体を同期します。例えばリポジトリを再構成して連続性がなくなった場合には、履歴情報の管理が崩れますので一旦全部削除してからやり直すことになります。 サブモジュールを追跡する git submodule update --remote 相当の処理を実行します。 起動時のリビジョン更新 ジョブを起動したときに git update やそれに付随する処理を実行します。毎回最新のプレイブックを使って処理を実行したいときにはここを有効にしておくことで、ワークフローを構成しなくても自動的に更新してからジョブを実行することができます。 ブランチの上書き許可 プロジェクト側ではまず git clone しますが、このオプションを有効にしてプロジェクトを同期しますと、ジョブテンプレート側でもブランチを選択して指定することができます。 複数のブランチを管理する Git リポジトリから一つのプロジェクトとして同期して、ジョブテンプレートを複数作ってそれぞれ使い分けたいというような場合に利用いただけます。本番環境と検証環境で分ける、などが考えられます。 プロジェクト外の roles や collections の利用 Git のリポジトリの中に roles/requirements.yml や collections/requirements.yml ファイルを置くことで、プロジェクトの同期時に ansible-galaxy コマンドを実行してプロジェクトの外から roles や collections を取ってくるということができます。具体的には、これらのコマンドをそれぞれ実行します。 $ ansible-galaxy role install -r roles/requirements.yml -p <project-specific cache location>/requirements_roles -vvv $ ansible-galaxy collection install -r requirements.yml -p <job tmp location> こちらの記事もご覧ください。 rheb.hatenablog.com 設定 「ジョブ設定」の画面にはこのプロジェクトについての設定がいくつかあります。 Default Project Update Timeout プロジェクトの更新にタイムアウトを設定します。 Run Project Updates With Higher Verbosity プロジェクトの更新ジョブの結果を詳細に出力します。プロジェクトの更新も内部的にはプレイブックを実行しています。 このプレイブックは /var/lib/awx/venv/awx/lib/python3.8/site-packages/awx/playbooks/project_update.yml にありますので、もしご興味ありましたらご覧ください。 Ignore Ansible Galaxy SSL Certificate Verification Collections を取ってくる先が private Automation Hub などに設定されていて TLS/SSL の証明書を自己署名にしているなどの理由で検証ができない場合には、このオプションを有効にすることで証明書の検証をしないようにすることができます。 Enable Role Download このオプションをオフにしますと、roles/requirements.yml がプロジェクトに含まれていても取りに行かなくなります。 Enable Collection(s) Download 上のオプションと同様に、このオプションをオフにしますと、collections/requirements.yml がプロジェクトに含まれていても取りに行かなくなります。 Follow symlinks ジョブテンプレートの設定ではプロジェクトからプレイブックを検出する処理を行うのですが、このオプションを有効にしますと、プロジェクトに含まれる symlink も追跡していくようになります。間違った設定が入っているときにはループしますので、これは有効にしないことをおすすめします。 おわりに Ansible Automation Platform の Controller (旧 Tower) で使われるプロジェクトについて一通り解説しました。 原理的にはプレイブック一式を Git で管理して取ってきて実行するということだけではあるのですが、Git との連携は利用目的や運用方法に応じて細かく制御することができるので、いろいろ使い方を検討いただけましたらと思います。 プレイブックを更新したときにどうプロジェクトに反映していくのがいいのかということもよく話題になりますが、「起動時のリビジョン更新」を有効にしていただいてジョブを実行したときの更新に任せることがまずは基本的な使い方です。他の方法が適している場合もあると思いますので、ここで解説したオプションを組み合わせることで実現できるかどうか、いろいろとご検討ください。 Ansible Automation Platform は Developer Subscription でもお試しいただけますので、ご興味持たれましたら試してみてください。 rheb.hatenablog.com Happy Automation!

Red Hatでソリューションアーキテクトをしている田中司恩( @tnk4on )です。 Googleが公開しているポッドキャスト「Kubernetes Podcast」のエピソード164はDaniel Walsh と Brent BaudeのRed Hatのエンジニア2名によるPodmanに関する内容です。 kubernetespodcast.com （下記はオリジナルのMP3からリンク) この内容を翻訳元から許可を受けて日本語に翻訳し、下記にて公開しました。 日本語版 は下記GitHubのページから参照ください。 github.com 本文だけで50分ぐらいあるコンテンツです。コンテナのセキュリティからDockerについて、Podman誕生の経緯とコンテナの標準化、そして最近盛り上がっているPodmanのデスクトップ開発とコミュニティとの対話など、かなり濃密に語られています。 Podmanに興味のある方には是非おすすめしたいコンテンツになっていますので、下記目次なども参考にしてぜひご覧ください。 -目次- (5:27) Main Start (6:54) SELinux and container security (9:36) Docker and History of container technologies (12:42) Project Atomic (13:59) Docker issues, and to Podman (18:40) Standardize and OCI (21:25) Podman features (28:59) Docker socket and Docker Compose (32:02) Podman in Podman (33:34) Container Runtime and CRI-O (35:25) containerd and CRI-O (37:16) Desktop experience for Podman (42:28) Remote client for Mac (45:13) Docker adjective (47:11) Double edge sword (48:34) Roadmap and priority (49:13) Discussion with the community (52:28) Podman Community (53:05) Ending 本ブログに掲載されているその他のPodman関連の翻訳記事は下記のリンクを参照ください。 Podman関連 翻訳記事 （宣伝）Red Hat Forum 2021のセッション登壇 今年のRed Hat Forum 2021は10月20日（水）にオンラインで開催します。 www.redhat.com その中のRED HAT SESSION (RHEL)(14:20-14:40)にて「 Podmanで始めるコンテナの世界 -Container journey to OpenShift- 」の内容で登壇いたします！ 時間は20分ほどですがPodmanに関する内容をギュギュッとまとめて最新情報までご紹介します。こちらも是非、Red Hat Forum 2021に事前登録のうえご参加ください。

OpenStackやOpenShiftなどのCloud製品を担当しているソリューションアーキテクトの輿水です。 今回は半年ぶりくらいにRed Hat OpenStack Platform（以降RHOSP）の話題を。RHOSP 15まではコミュニティ版OpenStackに対応するように半年ごとにリリースされておりましたが、RHOSP 16からは、すべてのコミュニティリリースに対応するのではなく特定のリリースをベースに選択し、長期間のサポートを提供するロングライフリリースとする方針になっています。コミュニティ版のリリースに追従しなくなったことで、RHOSPの次のバージョンのベースが何で、いつ頃リリースされるのか？という点が見えづらいとも言われますので、公開可能な情報はなるべく発信したいと思ってはおります。 コミュニティリリースの状況 RHOSPのライフサイクル RHOSPアップグレードパス コミュニティリリースの状況 コミュニティのOpenStackの現在のリリース状況と今後のリリースを見てみると、Yリリースまでが予定されております。 参照元： OpenStack Releases Train 2019年10月 Ussuri 2020年5月 Victoria 2020年10月 Wallaby 2021年9月→現在の最新 Xena 2021年10月予定 Yoga 2022年3月予定 RHOSP 16はTリリースであるTrainがベースであり、UリリースのUssuriの新機能の一部がバックポートされています。「RHOSP 17は、いつ頃リリースで、何がベースですか？」という質問もいただくのですが、長期間サポートのロングライフリリースですという事以外は、現時点では情報公開されておりません。 RHOSPのライフサイクル ライフサイクルに関するドキュメントには 英語版 と 日本語版 があるのですが、英語版が最新情報です。RHOSP 16以降は、16.0、16.1のようなマイナーバージョンが存在します。それぞれでサポート期間が異なりますが、RHOSP 16という括りでは16.0の一般提供開始日である2020年2月20日から16.2のELS終了日である2025年4月30日までの5年の長期サポートを提供します。16をご利用で2024年以降もサポートが必要な場合は、16.2を利用していただく必要があります。 バージョン 一般提供開始日 フルサポート終了日 サードパーティ認定期間終了日 メンテナンスサポート終了日 ライフサイクル終了日 延長ライフサイクルサポート（ELS）アドオン終了日 フルサポート 16.2 2021年9月15日 2023年4月30日 2022年5月31日 2024年4月30日 2024年4月30日 2025年4月30日 16.1 2020年7月29日 2022年4月30日 2021年5月31日 2024年4月30日 2024年4月30日 - 16.0 2020年2月20日 2020年10月27日 - - - - 延長サポート 13 2018年6月27日 2019年12月27日 2019年12月27日 2021年6月27日 2021年6月27日 2023年6月27日 10 2016年12月15日 2018年6月16日 2018年12月31日 2019年12月16日 2019年12月16日 2021年12月15日 RHOSPアップグレードパス 現在13をご利用中で延長ライフサイクルアドオンを追加していただいている場合は、2023年6月27日まではサポートされますので、その間に16.1以降への移行をご検討ください（タイミングによっては17がリリースされて13→17かもしれません）。13から16.1へのインプレースアップグレードのフレームワークは提供されています。 アップグレードに際しては以下の内容はあらかじめご確認ください 現在使用しているOSPのコンポーネントが16でもサポート対象である ワークロードが16に対応しているか 特にVNF（Virtual Network Function ）はベンダーによって対応状況が異なるので要注意 Ceph以外の3rdPartyのストレージを使用している場合は、プラグインが16に対応して認定されているか 16ではネットワークはOpen Virtual Networking (OVN)がデフォルトのメカニズムドライバーになってる ML2/OVS からML2/OVNへの移行については弊社TAMまたはGPSとの連携が必要（「 Open Virtual Network を使用したネットワーク（第3章） 」に「ML2/OVS から ML2/OVN への移行を試みる前に、事前サポートケースを作成する必要があります。事前サポートケースを作成しない場合、Red Hat では移行をサポートしません」という記載あり） 3rdPartyのSDNを利用している場合は、16に対応して認定されているか 10をご利用の場合は、今年の年末には延長ライフサイクルも終了となります。10→13のインプレースアップグレード方法（Fast Forward Upgrade）も提供されております。 RHOSP 16.2の詳細については、Red Hatから公式の発表が出るまでは大っぴらに書けないため、公式発表後にご紹介します。

今回はRed Hat 北山(OpenShiftのSA担当)がお届けします。 もうすぐKubeCon NAの季節ですね。ちなみに前夜祭(Oct 12th)にOpenShift Commons Gatheringが開催されますよっ!! commons.openshift.org いつもアドベントカレンダーの季節くらいしかブログは書かないのですが、ちょうど Kubernetes Meetup Tokyo #45 でLT の機会を頂いたので、その時間で触れられなかった内容を簡単にご紹介できればと思います。 今回は、まだあまり聞き慣れない Shipwright プロジェクトについてのご紹介です。 speakerdeck.com なお、まだ始まったばかりのプロジェクトなので、動向や紹介内容も温かい目で御覧くださいw OpenShift Build v1 まずは、これまでのOpenShiftのビルド機構についておさらい。 OpenShift BuildConfigs ところで皆さま、OpenShiftの BuildConfig って使用されていますか？ BuildConfig はOpenShiftにある、コンテナイメージの作成プロセスを自動化してくれる便利な独自機能の一つです。たとえば、Gitリポジトリ上のソースコード更新を契機に、Jenkinsパイプラインを動作させるといったビルドも、OpenShiftではこの BuildConfig を設定します。 独自機能と言いましたが、実体は BuildConfig というカスタムリソースです。 kind: BuildConfig apiVersion: build.openshift.io/v1 metadata: name: "ruby-sample-build" spec: runPolicy: "Serial" triggers: - type: "GitHub" github: secret: "secret101" - type: "ImageChange" source: git: uri: "https://github.com/openshift/ruby-hello-world" strategy: sourceStrategy: from: kind: "ImageStreamTag" name: "ruby-20-centos7:latest" output: to: kind: "ImageStreamTag" name: "origin-ruby-sample:latest" ここで重要なフィールドは、以下の3つ。 source フィールド : ビルドリソースに応じて、コードのGitリポジトリ、Dockerfile、またはバイナリのペイロードの場所を指定 strategy フィールド : ビルドの実行に使用するビルド戦略(Docker Build, s2i Build, Custom Build, Pipeline Build)を記述 output フィールド : ビルドされたコンテナイメージをプッシュするレジストリを指定 これらを使用することで、コンテナビルドにおける作業の簡略化を行っています。 BuildConfig はOpenShift v3の頃からあるリソースであり、クラウドネイティブ黎明期にはKubernetes上でコンテナをどのようにビルドするのかという観点で、先陣を切るビルド機構でした。 BuildConfigの課題 しかし、Kubernetesが普及してきたと同時に、 ビルドに関する機構 も多様化したことから、OpenShiftの BuildConfig だけでは標準化としての課題がいくつかでてきました。 BuildConfig 自体がOpenShift独自の機能(リソース)になってしまっている。(他のKubernetesとの親和性が薄い) BuildConfig の strategy フィールドで利用できるビルド方式が固定される。 BuildConfig に(Jenkinsの呼び出しや事後処理など)複数の機能/役割をもたせてしまっている。 これらを払拭すべく、OpenShiftでは次世代のクラウドネイティブなBuild機構 (OpenShift Builds v2) の導入検討が始まっています。 OpenShift Roadmap 引用: What's New in OpenShift 4.8 - Speaker Deck この候補に挙げられているのが、 Shipwright です。 Shipwrightの概要 Shipwright とはKubernetes上でコンテナイメージをビルドするための拡張可能なフレームワークです。 開発者に、コンテナツールの予備知識を必要とせず、最小限のYAMLを定義することでコンテナイメージを構築するためのアプローチを提供しています。 このYAMLを定義することによって、ビルドツールに依存せずに同じ書式(YAML形式)で好きなビルドツール利用してコンテナイメージをつくることができます。 Shipwright overview すでに The Continuous Delivery Foundation(CDF) のInqubationプロジェクトとして登録されています。 Shipwightのアーキテクチャ Shipwrightは、Kubernetes Operator パターンで提供されており、カスタムリソースとカスタムコントローラーからできています。ただし、 BuildConfig のようにOpenShift独自のコントローラーではなく、どのKubernetes上にも展開できるOperatorとして提供されています。 OperatorHub.ioへの登録も始まっています。 OperatorHub.io | The registry for Kubernetes Operators Shipwrightが管理するカスタムリソースは、主に以下の4つ。(2021/09時点) Build リソース: ビルド戦略、ビルド対象のソース(Gitリポジトリ)、ビルド後のイメージ出力先(コンテナレジストリ)を指定 BuildRun リソース: イメージのビルドを実行する (≒Tekton PipelinesのTaskRunを生成する) BuildStrategy リソース( ClusterBuildStrategy もある) : ビルドツールに応じた処理内容を抽象化する (≒Tekton PipelinesのTaskのStepを定義する) Shipwright architecture Shipwrightは、バックエンドでTekton PipelinesのTaskRunを利用することでビルド処理を行っています。 基本は Build オブジェクトにビルド定義を行い、 BuildRun オブジェクトをつくるとTekton Pipelinesによってビルド処理が実行されます。この際にビルド機構( BuildStrategy オブジェクト )を予め登録しておくことで、使いたいビルド戦略(ビルドツール)を Build オブジェクト内に定義できます。 Shipwrightの導入 ということで、新しいツールは実装してみるのが一番理解が早いので触ってみましょう。手順としては以下の順番で行います。 Tekton Pipelinesのインストール Tekton Pipelines CLIのインストール Shipwrightのインストール 1. Tekton Pipelinesのインストール まずは、Shipwrightで利用するTekton Pipelinesを入れておきます。 OpenShiftにTekton Pipeliensをインストールする場合 $ oc new-project tekton-pipelines $ oc adm policy add-scc-to-user anyuid -z tekton-pipelines-controller $ oc adm policy add-scc-to-user anyuid -z tekton-pipelines-webhook $ export TEKTON_PIPELINE_VERSION=v0.27.3 $ oc apply -f https://storage.googleapis.com/tekton-releases/pipeline/previous/${TEKTON_PIPELINE_VERSION}/release.notags.yaml OperatorHubからのインストール 1 も可能です。 KubernetesにTekton Pipeliensをインストールする場合 $ kubectl create namespace tekton-pipelines $ export TEKTON_PIPELINE_VERSION=v0.27.3 $ kubectl apply -f https://storage.googleapis.com/tekton-releases/pipeline/previous/${TEKTON_PIPELINE_VERSION}/release.yaml 2. Tekton Pipelines CLIのインストール Tekton Pipelinesのオブジェクト管理は専用の tkn コマンドを使うと便利です。合わせてインストールしておきましょう。 $ export TEKTON_CLI_VERSION=v0.20.0 $ curl -LO https://github.com/tektoncd/cli/releases/download/${TEKTON_CLI_VERSION}/tkn_${TEKTON_CLI_VERSION#v}_Linux_x86_64.tar.gz $ sudo tar xvzf tkn_${TEKTON_CLI_VERSION#v}_Linux_x86_64.tar.gz -C /usr/local/bin/ tkn $ tkn version Client version: 0.20.0 Pipeline version: v0.27.3 3. Shipwrightのインストール ShipwrightのControllerは、 shipwright-build namespacesにインストールされるため、あらかじめ設定しておきます。 $ kubectl create namespace shipwright-build ## OpenShiftの場合のみSCCの設定 $ oc adm policy add-scc-to-user anyuid -z shipwright-build-controller -n shipwright-build 次にShipwrightのCRDとControllerをインストール。 $ kubectl apply -f https://github.com/shipwright-io/build/releases/download/v0.5.1/release.yaml 以上でShipwrightの設定は完了です。 Shipwrightの利用 いよいよShipwrightのオブジェクトを登録してビルドを開始しましょう。今回は sample-shipwright namespaceという名前空間でビルドを行います。なお、kubens 2 は事前に入れておいてくださいね。 $ kubectl create namespace sample-shipwright $ kubens sample-shipwright OpenShift上で実装する場合は、SCCの設定から始めてください。 $ oc adm policy add-scc-to-user anyuid -z default -n sample-shipwright $ oc create serviceaccount pipeline -n sample-shipwright $ oc adm policy add-scc-to-user privileged -z pipeline -n sample-shipwright $ oc adm policy add-role-to-user edit -z pipeline -n sample-shipwright Shipwrightの利用は、以下の手順で行います。 BuildStrategy オブジェクトの登録 Build オブジェクトの登録 BuildRun オブジェクトの登録 a. BuildStrategy オブジェクトの登録 はじめに BuildStrategy オブジェクトを設定します。基本の BuildStrategy オブジェクトには以下のような種類があります。 Buildah Buildkit Cloud Native Buildpacks Kaniko Ko s2i BuildStrategy オブジェクトは各名前空間内に設定できますが、クラスター全体でビルド機構を再利用する場合は ClusterBuildStrategy オブジェクトに設定します。 そして、今回はこの ClusterBuildStrategy オブジェクトを登録します。 なお、基本の ClusterBuildStrategy オブジェクトは、 プロジェクトに用意 されており、一つ一つ登録せずとも1コマンドですべて登録が可能です。 $ kubectl apply -f https://github.com/shipwright-io/build/releases/download/nightly/default_strategies.yaml $ kubectl get cbs --show-kind=true NAME clusterbuildstrategy.shipwright.io/buildah clusterbuildstrategy.shipwright.io/buildkit clusterbuildstrategy.shipwright.io/buildpacks-v3 clusterbuildstrategy.shipwright.io/kaniko clusterbuildstrategy.shipwright.io/ko clusterbuildstrategy.shipwright.io/source-to-image BuildStrategy オブジェクトの内容 ちなみに、この BuildStrategy オブジェクトの中身を見ると、Tekton Pipelinesの Task の内容ととても似ていることがわかります。つまり、各Step(buildStep)でTekton PipelinesのTaskRunを生成するための内容が定義されています。 apiVersion: shipwright.io/v1alpha1 kind: ClusterBuildStrategy metadata: name: kaniko spec: buildSteps: - name: build-and-push image: gcr.io/kaniko-project/executor:v1.6.0 workingDir: $(params.shp-source-root) … command: - /kaniko/executor args: - --skip-tls-verify=true - --dockerfile=$(build.dockerfile) - --context=$(params.shp-source-context) - --destination=$(params.shp-output-image) - --oci-layout-path=/kaniko/oci-image-layout - --snapshotMode=redo - --push-retry=3 resources: limits: cpu: 500m memory: 1Gi requests: cpu: 250m memory: 65Mi b. Build オブジェクトの登録 さて、つぎに Build オブジェクトを登録しましょう。 認証情報の登録 あらかじめビルド時に使用するGitリポジトリやコンテナレジストリ用の認証情報が必要です。通常のPullSecret同様に認証情報をSecret形式で登録すればよいのですが、このSecretを確認するのは最終的にTekton Pipelinesです。したがって、Tekton Pipelinesで認識できる形でSecret登録しておくと認証が行われます。 ここではAccess Tokenを使ったBasic認証を行っています。 ## GitLab.comの場合 $ export REPOSITORY_SERVER=gitlab.com $ export REGISTRY_SERVER=registry.gitlab.com $ export REGISTRY_REPO=<your registory repo name> $ export REGISTRY_USER=<your registry name> $ export REGISTRY_PASS=<your password> $ cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Secret metadata: name: gitlab-token annotations: tekton.dev/git-0: https://${REPOSITORY_SERVER} tekton.dev/docker-0: https://${REGISTRY_SERVER} build.shipwright.io/referenced.secret: "true" type: kubernetes.io/basic-auth stringData: username: ${REGISTRY_USER} password: ${REGISTRY_PASSWORD} EOF Build オブジェクトの内容 Build オブジェクトには以下の3つを定義します。 source フィールド: ビルド対象のソースコード、またはDockerfileが入ったGitリポジトリの指定 strategy フィールド: ClusterBuildStrategy で登録したビルド機構の指定 output フィールド: ビルド後のコンテナイメージ格納先の指定 これらに先程登録した認証情報を関連付けます。 $ cat <<EOF | kubectl apply -f - apiVersion: shipwright.io/v1alpha1 kind: Build metadata: name: go-tutorial-kaniko spec: source: url: https://github.com/shipwright-io/sample-go contextDir: docker-build strategy: name: kaniko kind: ClusterBuildStrategy output: image: ${REGISTRY_SERVER}/${REGISTRY_USER}/${REGISTRY_REPO}/go-tutorial credentials: name: gitlab-token EOF 登録されているかを確認しておきましょう。ここでOpenShiftを利用している方は、APIの呼び出しに気をつけて下さい。OpenShiftにはもともと BuildConfig 用のリソース(Build v1=builds.config.openshift.io)があるため、 $ kubectl get builds としても出力されません。 $ kubectl get crd |grep builds builds.config.openshift.io 2021-09-23T06:36:15Z builds.shipwright.io 2021-09-23T08:15:09Z … $ kubectl get builds.shipwright.io go-tutorial-kaniko NAME REGISTERED REASON BUILDSTRATEGYKIND BUILDSTRATEGYNAME CREATIONTIME go-tutorial-kaniko True Succeeded ClusterBuildStrategy kaniko 4d2h c. BuildRun オブジェクトの登録 最後に BuildRun オブジェクトを登録し、ビルドを実行します。 BuildRun オブジェクトでは、 buildRef フィールドで先程登録した Build オブジェクトを指定します。 $ cat <<EOF | kubectl create -f - apiVersion: shipwright.io/v1alpha1 kind: BuildRun metadata: generateName: go-tutorial-kaniko-run- spec: buildRef: name: go-tutorial-kaniko EOF これらを登録するとTekton TaskRunによるビルドが始まり、うまくいくと Build オブジェクトで指定したコンテナレジストリにイメージが格納されます。 $ tkn taskrun list NAME STARTED DURATION STATUS go-tutorial-kaniko-run-w4ssd-z446p 13 seconds ago --- Running $ tkn taskrun logs -L … [build-and-push] INFO[0114] COPY --from=build /tmp/helloworld ./helloworld [build-and-push] INFO[0114] Taking snapshot of files... [build-and-push] INFO[0114] ENTRYPOINT [ "./helloworld" ] [build-and-push] INFO[0114] EXPOSE 8080 [build-and-push] INFO[0114] cmd: EXPOSE [build-and-push] INFO[0114] Adding exposed port: 8080/tcp [build-and-push] INFO[0114] Pushing image to registry.gitlab.com/<your registry name>/shipwright-tutorial/go-tutorial [build-and-push] INFO[0122] Pushed image to 1 destinations ビルドが成功したら、自身のコンテナレジストリからも確認を行って見てください。 GitLab Contaner Registry 今回は Kaniko を使ってBuildを行いましたが、 Build オブジェクトの ClusterBuildStrategy を切り替えると、別の方式でビルドが可能です。 またTekton PipelinesのTaskRunの内容を見るとShipwrightの仕組みがよくわかります。 BuildRun オブジェクトはTekton Pipelinesの Task オブジェクトは生成せずに、TaskRunの spec.taskSpec フィールドを使って、 TaskRun オブジェクトを生成しています。 $ tkn task list No Tasks found ## TaskRunの名前を指定 $ kubectl get taskrun go-tutorial-kaniko-run-w4ssd-z446p -o yaml |less つまり、このTaskRunの生成元が BuildStrategy オブジェクトということです。そのため、 BuildStrategy オブジェクト自体をカスタマイズすると、いろんなビルドに対応することが可能です。 このあたりのカスタマイズは、参考資料の Project Shipwright In Depth も合わせて御覧ください。 まとめ ということで、 Shipwright の導入についてご紹介しました。すこし興味をもっていただけたでしょうか？ 今後のOpenShift Roadmapで紹介される OpenShift Builds v2 についても、楽しみにしておいてください!! 参考資料 The future of Red Hat OpenShift builds Project Shipwright In Depth Project Shipwright Introduction to Shipwright 最後に宣伝 最後にとてもだいぢなお知らせをしておきます。ちなみに、ここが一番重要です。 Tekton / Argoを使ったCI/CDの新しい本が出るので、是非お買い求めください。 www.amazon.co.jp いじょ。またねー。 pipelines-tutorial/install-operator.md at master · openshift/pipelines-tutorial · GitHub ↩ https://github.com/ahmetb/kubectx#installation ↩