クラウドインフラ全般を担当しているソリューションアーキテクトの伊藤です。 今回はRed Hat OpenStack Platform 16の新機能と改善ポイントについて紹介いたします。 OpenStackはクラウドインフラを提供するソフトウェアとして開発されており、APIで仮想マシンやネットワーク、ストレージなどのリソースをコントロールすることができ、 AnsibleやOpenShiftとの連携強化が毎バージョン行われています。 RHOSP16のリリースノート全文は以下のURLをご参照下さい。 access.redhat.com ■はじめに 2020年2月20日にRHEL8初の長期サポート版のRHOSPがリリースされました。 RHOSP16は去年10月にリリースされたUpstream版のOpenStack Trainをベースにしており、今後リリースされる予定となっているOpenStack Ussuriで搭載される重要な機能が、今回リリースされたRHOSP16にも反映する予定となっています。 RHOSP16ではOpenShiftとのインテグレーションが強化されており、プロキシ環境での利用やKuryrによるネットワーク統合、またオンプレ環境でのOpenShiftのオートスケールが利用できます。 その他、2020年1月下旬にリリースされたRed Hat Ceph Storage 4をRHOSPからデプロイすることができるようになっており、RHEL8をベースにしたRHOSP16とRHCS4を合わせて使う事でパフォーマンスが向上しつつ運用性が向上しています。 ■新機能、変更点 ライフサイクルの変更が行われた RHOSP16の全体的なサポート期間は5年と変わっておりませんが、各メンテナンスフェーズが遷移するタイミングが変更されています。 access.redhat.com ホストOSがRHEL8に変更されたため、ゲストOSのサポート状況が変わった RHOSP16ではホストOSにおいてRHEL8を使用しています。 以下の表を確認するとRHEL8がホストOSの場合、サポート可能なゲストOSはRHEL6,7,8、Windows2012R2,2016,2019、SLES10,11,12,15となっています。 access.redhat.com ゲストOSとしてWindows Server 2019サポート RHOSP16ではWindows Server 2019をサポートしています。RHOSP13においてもWindows Server 2019のゲストサポートがバックポートされました。 大規模環境のためのCells V2 RHOSP16を用いて大規模なシングルクラスタを構成する場合、Cells V2によって従来大規模環境でスケールの観点でボトルネックになりやすかった DBとMQを各セルに配置することでスケーラビリティを確保することが可能になりました。 access.redhat.com ネットワーク機能を提供するNeutronのデフォルトプラグインがML2/OVSからML2/OVNに変更 RHOSP15よりML2/OVNがデフォルトのネットワークプラグインとなっています。 OVNではGeneveプロトコルを用いてオーバーレイネットワークが構成されており、L2の接続性が向上しています。 また、ML/OVSではDVRを用いて分散ルータを構成していましたが、ML2/OVNでは分散構成が標準です。 access.redhat.com 作成済みのCinderボリュームを、インスタンスにアタッチした状態で拡張することが可能 Cinderで作成したボリュームを、in-useステータスつまり稼働中であっても拡張することができます。 この機能が有効であるかどうかはCinderバックエンドで利用するストレージ次第です。 DirectorによるRHCSv4の同時デプロイ OpenStack Directorは従来よりOpenStackとCephを同時にデプロイすることが可能でしたが、 RHOSP16からは新しいバージョンであるRed Hat Ceph Storage 4をデプロイすることが可能になりました。 Cinderボリュームのクローンにおける暗号化キーの都度変更 Cinderはクローンした暗号化ボリュームの暗号化キーを自動で変更することができます。 ボリューム毎に異なる暗号化キーを自動で利用することになるので、セキュリティの観点での安全性が向上しました。 CinderバックエンドのAvailability ZoneをDirectorでデプロイ時に設定可能になった 従来、Cinderバックエンドを複数のAvailability Zoneを用いて構成する場合は、 Directorがデプロイ後に運用者がAvailability Zoneを指定する必要がありましたが、デプロイ時に指定することが可能になっています。 こちらはサポート状況がTechnology Previewのステータスになっています。 OpenShift4とのインテグレーション OCP4.3のインフラストラクチャプロバイダーとしてOpenStackを選択する場合、AWSなどパブリッククラウドをインフラとして利用する時と同様に プロキシ環境、オフライン環境、OCPで使うCoreOSイメージの自動ダウンロード、Machine APIを利用したノードのオートスケールに対応しています。 またOpenStackとOpenShiftのネットワーク機能を統合するKuryrもサポートされています。 https://docs.openshift.com/container-platform/4.3/installing/installing_openstack/installing-openstack-installer-custom.html docs.openshift.com シングルノードデプロイ RHOSP16のDirectorは、より容易に検証が行えるように1ノードにコントローラ、コンピュート機能を統合したAll-in-oneノードをデプロイすることができます。 access.redhat.com Undercloud minion RHOSP16から提供されているUndercloud minionという機能を用いることでheat-engineとironic-conductorをスケールアウトすることができるようになります。 UndercloudのパフォーマンスつまりOvercloudのデプロイ、更新速度を向上させることが可能になります。 こちらはサポート状況がTechnology Previewのステータスになっています。 access.redhat.com DirectorからRedfishでOvercloudノードのBIOS変更を実施 UndercloudからOvercloudのサーバのBIOS変更を実施することが可能になりました。 サーバに備わっているRedfish APIをSushyライブラリからコントロールしています。 こちらはサポート状況がTechnology Previewのステータスになっています。 ■最後に OpenStackは初回リリースから10年近くになるソフトウェアになります。IaaSとしての利用に十分な機能、安定性を備え、NFV、Edge、開発者向けの開発環境クラウドなど利用が広がっています。 今回更にエンタープライズ向けのコンテナ環境を提供するOpenShift、オペレータが行うコマンド以外の企業全体のIT業務の自動化に貢献するAnsible Towerとの連携が強化されています。 Red Hatでは恵比寿の社内にOpenStackの検証を行う環境を備えています。 プライベートクラウドを業務に取り入れるために、想定した業務フローとOpenStackが適合するか検証したいがテスト環境が無いといった、プライベート基盤構築を進めるにあたってのPoC環境についてもお気軽にご相談下さい。

レッドハットでインテグレーションのためのミドルウェア製品のテクニカルサポートを担当している山下です。今回は Jiri Pechanec さんによる「DebeziumとApache Camelのインテグレーションシナリオ 」の翻訳記事です。 今回の記事では、Debeziumによってデータベースからの変更をキャプチャしてKafkaへと流し、CamelによるEIPを通して、Twitterとメールに配信する、というシナリオを説明します。 ところ今回の記事では軽く触れながらも流しているのですが、Kafka Connectランタイム上で Camel のコンポーネントを動作させる プロジェクト が進んでいます。これによってCamelが既に持っている様々なシステムとのアダプタを利用して、容易にKafkaとのデータの出し入れができるようになっていくはずです（もちろんオープンソースで！）。個人的にはこちらも楽しみにしているところ。 [原文] Integration Scenarios with Debezium and Apache Camel by Jiri Pechanec あんまり翻訳がうまくないのは許してください (^^; Debeziumの典型的な使用例の1つは、チェンジデータキャプチャ(Change Data Capture)を使用して、レガシーシステムを組織内の他のシステムとインテグレーションすることです。 この目標を達成する方法は複数あります。 Debeziumを使用してデータをKafkaに書き込み、続いてKafka StreamsパイプラインとKafka Connectコネクターの組み合わせて、他のシステムに変更を配信する Javaスタンドアロンアプリケーションで Debezium Embedded engine を使用し、プレーンJavaを使用してインテグレーションコードを記述する；これはたびたび変更イベントをAmazon Kinesis、Google Pub/Subなどの代替メッセージングインフラストラクチャに送信するために使用される 既存のインテグレーションフレームワークまたはサービスバスを使用してパイプラインロジックを表現する この記事では、3番目のオプションである専用のインテグレーションフレームワークに焦点を当てます。 Apache Camel Camel は、異なるシステムやサービス間でデータの読み取り、変換、ルーティング、書き込みを行えるようにするオープンソースのインテグレーションフレームワークです。 サードパーティシステムへのインターフェイスとなる大量の既製 コンポーネント や、 EIP : エンタープライズインテグレーションパターン による実装を支援します。 この組み合わせにより、開発者は対象システムに簡単に接続し、宣言的なDSLを使用してインテグレーションパイプラインを表現できます。 Camel と Debezium Camel 3 は2019年末にリリースされ、新しく再設計が行われただけでなく、Debeziumコンポーネントがコードベースに追加されました 。 また、CamelをKafka Connectランタイムで コネクター として使用できるようにします。 この投稿はDebeziumコンポーネントの使用のみに焦点を当てており、後者のオプションについては今後の投稿で取り上げるつもりです。 Debezium MySQL Connector Component Debezium PostgreSQL Connector Component Debezium SQL Server Connector Component Debezium MongoDB Connector Component ご覧のように、すべての 非インキュベーション Debeziumコネクタは専用コンポーネントで表されます。 このソリューションの利点は、依存関係を完全に分離し、コネクタインスタンスのタイプセーフな構成としていることです。 内部的にコンポーネントは、 Debezium エンベデッドエンジン を含んだCamelイベントドリブン コンシューマ を用いて、Debezium エンドポイント を公開します。 Example 例として、StackOverflowのようなシンプルな質問と回答（Q＆A）アプリケーションを作成しました。 REST APIを使用すると、新規の質問や、データベースに保存された既存の質問への回答を投稿できます。 アプリケーションによって生成されたデータの変更（たとえば、新規の質問や回答が作成された場合）は、Debeziumを介してキャプチャされ、Camelパイプラインに渡されます。 GitHubでサンプルの完全な ソースコード を見つけることができます。 アプリケーションによって生成されたデータの変更（新しい質問または回答が作成された場合など）は、Debeziumによってキャプチャされ、SMTPサーバーを通して電子メールを送信してTwitterアカウントにツイートを投稿するCamelパイプラインに渡されます。完全な ソースコード はGitHubにあります。 トポロジ ソリューショントポロジには複数のコンポーネントがあります： Figure 1. The Deployment Topology Q＆Aアプリケーションは Quarkus スタックを使用して実装され、REST APIを公開して質問と回答を作成 アプリケーションはPostgreSQLデータベースにデータを保存 Camel routeは、組み込みの Infinispan ストアを使用してその状態を保持する（質問と回答を集約するオブジェクトの構築に使用）、プレーンなJavaアプリケーションとして実行され、電子メールおよび関連するTwitterアカウントを通して質問に回答 MailHog 電子メールを送信するためのコンテナで実行されているSMTPサーバー Q＆Aアプリケーション ソースアプリケーションは、Quarkusに基づくシンプルなRESTサービスです。 PostgreSQLデータベースに保存されている「1：n」リレーションを使用して、「Question」と「Answer」の2つのエンティティを管理します。 Figure 2. The Q&A Backend Service Entity Relationship Diagram エンティティはREST APIを使用して作成され、自動的にそれらの間を関連付けます。 The Camel Pipeline Camelパイプラインは、以下のビジネスルールを表現します。 作成または更新された質問ごとに、質問の作成者にメールを送信します 作成または更新されたすべての回答について、質問と回答の作成者の両方にメールを送信します 質問の回答が3つに達したら、それに関する専用のTwitterアカウントにツイートを投稿します このビジネス要件は、このEIP図で記述されたパイプラインに置き換えることができます。 Figure 4. The Camel Pipeline コードの説明 Debezium Camelコンポーネントを使用するには、以下の依存を pom.xml ファイルに追加する必要があります。 <dependencyManagement> <dependencies> <dependency> <groupId> org.apache.camel </groupId> <artifactId> camel-bom </artifactId> <version> ${version.camel} </version> <type> pom </type> <scope> import </scope> </dependency> <!-- Use required Debezium version --> <dependency> <groupId> io.debezium </groupId> <artifactId> debezium-connector-postgres </artifactId> <version> ${version.debezium} </version> </dependency> <dependency> <groupId> io.debezium </groupId> <artifactId> debezium-embedded </artifactId> <version> ${version.debezium} </version> </dependency> <dependency> <groupId> io.debezium </groupId> <artifactId> debezium-core </artifactId> <version> ${version.debezium} </version> </dependency> </dependencies> </dependencyManagement> <dependencies> <dependency> <groupId> org.apache.camel </groupId> <artifactId> camel-core </artifactId> </dependency> <dependency> <groupId> org.apache.camel </groupId> <artifactId> camel-debezium-postgres </artifactId> </dependency> </dependencies> The pipeline logic itself is defined in QaDatabaseUserNotifier class. Its main route looks like tis: パイプラインロジック自体は QaDatabaseUserNotifier で定義されています。 Camel ルートは以下のようになります。 public class QaDatabaseUserNotifier extends RouteBuilder { @Override public void configure() throws Exception { from( "debezium-postgres:localhost?" + "databaseHostname={{database.hostname}}" + "&databasePort={{database.port}}" + "&databaseUser={{database.user}}" + "&databasePassword={{database.password}}" + "&databaseDbname=postgres" + "&databaseServerName=qa" + "&schemaWhitelist={{database.schema}}" + "&tableWhitelist={{database.schema}}.question,{{database.schema}}.answer" + "&offsetStorage=org.apache.kafka.connect.storage.MemoryOffsetBackingStore" ) .routeId(QaDatabaseUserNotifier. class .getName() + ".DatabaseReader" ) // ** #1 ** .log(LoggingLevel.DEBUG, "Incoming message ${body} with headers ${headers}" ) .choice() // ** #2 ** .when(isQuestionEvent) .filter(isCreateOrUpdateEvent) // ** #3 ** .convertBodyTo(Question. class ) // ** #4 ** .log(LoggingLevel.TRACE, "Converted to logical class ${body}" ) .bean(store, "readFromStoreAndUpdateIfNeeded" ) // ** #5 ** .to(ROUTE_MAIL_QUESTION_CREATE) // ** #6 ** .endChoice() .when(isAnswerEvent) .filter(isCreateOrUpdateEvent) .convertBodyTo(Answer. class ) .log(LoggingLevel.TRACE, "Converted to logical class ${body}" ) .bean(store, "readFromStoreAndAddAnswer" ) .to(ROUTE_MAIL_ANSWER_CHANGE) .filter(hasManyAnswers) // ** #7 ** .setBody().simple( "Question '${exchangeProperty[aggregate].text}' has " + "many answers (generated at " + Instant.now() + ")" ) .to(TWITTER_SERVER) .end() .endChoice() .otherwise() .log(LoggingLevel.WARN, "Unknown type ${headers[" + DebeziumConstants.HEADER_IDENTIFIER + "]}" ) .endParent(); from(ROUTE_MAIL_QUESTION_CREATE) // ** #6 ** .routeId(QaDatabaseUserNotifier. class .getName() + ".QuestionNotifier" ) .setHeader( "To" ).simple( "${body.email}" ) .setHeader( "Subject" ).simple( "Question created/edited" ) .setBody().simple( "Question '${body.text}' was created or edited" ) .to(SMTP_SERVER); } @Converter public static class Converters { @Converter public static Question questionFromStruct(Struct struct) { // ** #4 ** return new Question(struct.getInt64( "id" ), struct.getString( "text" ), struct.getString( "email" )); } @Converter public static Answer answerFromStruct(Struct struct) { // ** #4 ** return new Answer(struct.getInt64( "id" ), struct.getString( "text" ), struct.getString( "email" ), struct.getInt64( "question_id" )); } } } 説明は以下のとおりです。 #1 from はDebeziumソースエンドポイントです。 URIパーツは、コネクター構成オプションに直接マップします #2 パイプラインロジックは、変更イベントタイプに応じてスプリットされます。これはソーステーブルの識別子（ <server_name>。<schema_name>。<table_name> ）を含んだ CamelDebeziumIdentifier のヘッダーに基づきます #3 パイプラインは、更新と削除のみを処理できるようになりました。これはメッセージ Envelope の op フィールドを含む CamelDebeziumOperation ヘッダーに基づきます ＃4 Kafka Connectの Struct 型は、パイプラインで使用される論理型に変換されます。変換は、カスタムのCamel コンバーターによって実行されます。手軽に利用できる DebeziumTypeConverter を使用して Struct を Map に変換することもできますが、しかしこれはパイプラインロジックがテーブル構造に強く結合してしまいます。 ＃5 メッセージストア と通信するルートが呼び出されます。Infinispanキャッシュに基づいてメッセージの集約を作成します。メッセージストアは、質問がすでに保存されているかどうかを確認します。新しい集約が作成されてない場合には保存し、そうでない場合には保存されている集約が新しいデータで更新されます。 ＃6 メールメッセージをフォーマットして、SMTPエンドポイントを介して質問作成者にメール配信するルートが呼び出されます。 ＃7 回答メッセージタイプに関連するルート部分は非常に似ています（回答は質問集約に追加されます）。主な違いは、集約に3つの回答が含まれる場合のTwitterメッセージの投稿です。 補足ですが、シンプルな例とするために、揮発的なメモリを使用してDebeziumオフセットを格納しています。 永続ストレージの場合にはファイルベースのオフセットストアを使用するか、Infinispanによるカスタムオフセットストア実装を作成してキャッシュにオフセットの保存を任せることもできます。 デモ デモを実行するには、適切なAPIキーとシークレットを備えたTwitter 開発者アカウント が必要です。 アプリケーションディレクトリに移動して、すべてのコンポーネントをビルドしてください。 $ mvn clean install サービスを開始します（独自のTwitter API資格情報を提供します）: $ env TWITTER_CONSUMER_KEY=<...> TWITTER_CONSUMER_SECRET=<...> TWITTER_ACCESS_TOKEN=<...> TWITTER_ACCESS_TOKEN_SECRET=<...> docker-compose up 別のターミナルで質問とそれに3つの回答を作成します: $ curl -v -X POST -H 'Content-Type: application/json' http://0.0.0.0:8080/question/ -d @src/test/resources/messages/create-question.json $ curl -v -X POST -H 'Content-Type: application/json' http://0.0.0.0:8080/question/1/answer -d @src/test/resources/messages/create-answer1.json $ curl -v -X POST -H 'Content-Type: application/json' http://0.0.0.0:8080/question/1/answer -d @src/test/resources/messages/create-answer2.json $ curl -v -X POST -H 'Content-Type: application/json' http://0.0.0.0:8080/question/1/answer -d @src/test/resources/messages/create-answer3.json Twitterアカウントには、『質問「犬にはいくつの足がありますか？』などのテキストを含む新しいツイートが含まれているはずです。また、[MailHogサーバーUI]（http：// localhost：8025 /）には次のようなメッセージが表示されます。 Figure 4. The MailHog Messages まとめ Apache Camelは、システムインテグレーションシナリオを実装するための非常に興味深いオプションです。外部のメッセージングインフラストラクチャを必要とせずに、Debeziumコンポーネントを使用してスタンドアロンのCamelルートを展開するのは非常に簡単で、データの変更をキャプチャし、複雑なルーティングおよび変換操作を実行できます。 Camelは、複雑なサービスオーケストレーションに含まれる可能性のあるさまざまなシステム用の100を超えるコネクタだけでなく、EIP : エンタープライズインテグレーションパターンの完全な実装を開発者に提供します。 今回の例の完全なソースコードは GitHub から入手できます。 Debeziumについて Debeziumは、既存のデータベースをイベントストリームに変換するオープンソースの分散プラットフォームです。アプリケーションは、データベース内にコミットされた行レベルの変更をほとんど瞬時に確認して反応することができます。 Debeziumは Kafka の上に構築され、特定のデータベースを監視する Kafka Connect 互換コネクタを提供します。Debeziumはデータ変更の履歴をKafkaログに記録するため、アプリケーションはいつでも停止や再起動することができ、実行中に見逃したすべてのイベントを簡単に消費できるため、すべてのイベントを正しく完全に処理することができます。 Debeziumは Apache License、Version 2.0 であり オープンソース です。 参加しよう Debeziumに興味を持ち試してみてほしいと思います。 Twitter @debezium 、 Gitterでチャット 、または メーリングリスト でコミュニティと話すことができます。 すべてのコードは GitHub でオープンソースです。したがって、コードをローカルでビルドし、既存のコネクタを改善し、さらにコネクタを追加できます。 問題を発見したり、Debeziumの改善方法についてアイデアをお持ちの場合は、お知らせいただくか 問題を記録 してください。 Jiri Pechanec Jiriは、Red Hatのソフトウェア開発者（そして元QAエンジニア）です。 Javaおよびシステムインテグレーションプロジェクトとそのタスクで多くのキャリアを積んできました。チェコ共和国のブルノの近くに住んでいます。 [ github ] [ linkedin ]

この記事は、Quarkus.io のブログ記事、 Quarkus wins DEVIES award の翻訳記事です。 2020年1月22日、私たちはQuarkusがDeveloperWeek DEVIES 賞のBest Innovation in:Code Frameworks/Libraries部門で受賞したことを知りました。KubernetesネイティブなJavaスタックとしてのQuarkusは、コンテナやマイクロサービス、サーバレスといったクラウドネイティブなアプリケーションアーキテクチャにJavaを適合させる、現代のアプリケーション開発における根本的な変化を表しています。Java開発者は、Quarkusを使用して、起動時間が短く、メモリ使用量が大幅に少ないアプリケーションを構築できます。Quarkusは、すぐに使える状態で、一般的なJava標準、フレームワーク、およびライブラリに対応しています。開発者はアプリケーションに必要なJavaフレームワークを選ぶことができ、JVMモードで実行することも、コンパイルしてネイティブモードで実行することもできる。Quarkusには、実行中のアプリケーションにソースコードの変更を即座に適用するライブコーディング、組み込みのマネージドイベントバスを使用した命令型プログラミングとリアクティブプログラミング、構成の統一、ネイティブ実行可能ファイルの容易な生成など、開発者の生産性向上機能が含まれています。Quarkusは従来のJavaに比べてメモリ消費量が1/10になるようにアプリケーションを構築し、起動時間が300倍速くなり、クラウドリソースのコストを大幅に削減することができます。 Quarkusコミュニティはこの賞を受賞することに興奮しており、DeveloperWeek DEVIESの審査員の信任投票に感謝の意を表したいです。私たちにとって、これは正しい道を歩んでいることを意味し、コミュニティのすべてのメンバーが日々プロジェクトに注ぎ込んでいる骨の折れる努力を正当化するものです。これにより、私たちは、ハイブリッドクラウドの世界で開発者や組織のニーズを満たすために、Quarkusにイノベーションをもたらし続けるために、さらに懸命に取り組むことができます。 最後に、コード、プルリクエスト、問題作成、ドキュメント、ウェビナー、ビデオ、書籍、Quarkusのヒント、記事、ブログ投稿など、Quarkusの開発に貢献してくれた世界中のすべての人に感謝したいと思います。現在進行中の革新的な仕事がたくさんありますので、この機会に私たちのコミュニティに参加していただきたいと思います。あなたの意見と貢献は、Quarkusが今後も成長を続け、開発者コミュニティのすべての人々に貢献するのに役立ちます。 Quark（物質の基礎単位であると考えられている理論上の粒子）してハドロン（強い力を及ぼし合う素粒子の総称）を作り続けよう!

Red Hat ソリューションアーキテクトの小島です。 エンタープライズ用途でコンテナアプリを開発・運用していく際には、コンテナイメージのバックアップ、バージョン管理、構成やセキュリティ基準の標準化などのいくつかの理由により、専用のコンテナイメージレジストリが必要になってきます。本記事ではKubernetesやOpenShiftなどのコンテナ環境に利用できる、分散型コンテナイメージレジストリQuayをご紹介します。 Quayとは Quayの提供形態 Operatorを利用したRed Hat Quayのインストールの前準備 Operatorを利用したRed Hat Quayのインストール (GUI) Operatorを利用したRed Hat Quayのインストール (CLI) Red Hat Quayの使用 Clairによるコンテナイメージ脆弱性の静的解析 まとめ References Quayとは QuayはKubernetesやOpenShiftなどのコンテナ環境用のコンテナイメージレジストリです。最初は2013年にQuay.ioというSaaS型のサービスとして提供していたものを、2014年にCoreOSが買収してからオンプレミス版のQuay Enterpriseも提供するようになりました。そして2018年1月にRed HatがCoreOSを買収してからは、Quay EnterpriseをRed Hat Quayという名前に変更して提供しています。元々OpenShift環境の場合だと自動的に内部レジストリが作成され、それを利用して複数の開発チームでのコンテナイメージの共同開発・メンテナンスができるのですが、Quayは下記のような特徴を備えており、エンタープライズでのレジストリ利用をより強力に促進しています。 リポジトリ使用状況の可視化 (いつ誰がイメージをPush/Pullしたか、などの情報を保持) Clairと連携したコンテナイメージ脆弱性情報の可視化 リポジトリへのイメージPushやイメージ脆弱性検知時などのイベントの自動通知 OpenShift環境とは独立した認証情報の利用 (LDAPやOpenID Connectなど) registry.redhat.ioなど外部レジストリからのリポジトリの自動ミラーリング Geo-Replicationによる遠隔地への非同期コピー GitHubなどのWebhookを利用した、Dockerfileからのイメージ自動ビルド OAuth 2 RESTful APIによる外部アプリとの連携 様々なパブリック/プライベートのクラウドストレージサービスをQuayのバックエンドストレージとして利用可能 2020年2月時点では、Amazon S3, Azure Blob Storage, Google Cloud Storage, Ceph Object Gateway, OpenStack Swift, OpenShift Container Storage 4 といったクラウドストレージサービスを、Quayのバックエンドストレージとして利用できます。OpenShift Container Storageについては下記をご参照ください。 rheb.hatenablog.com 上記の特徴を備えているため、セキュリティを考慮したDevSecOpsや、大規模なKubernetes/OpenShift環境用の分散レジストリとしての利用がQuayのメインユースケースとなります。分散レジストリとして利用する場合はリポジトリミラーリングやGeo-Replicationによって、グローバルな環境でコンテナイメージを共有・開発・運用していくイメージが一例として挙げられます。 なお、Kubernetes/OpenShiftのマルチクラスタに対して、1つのAPIからサービスをデプロイできるようになる Kubernetes KubeFed というOSSのプロジェクトがあります。こうした機能とQuayやOpenShiftを組み合わせると、大規模なコンテナ環境に対してセキュリティ基準や運用手法を統一できるため、ガバナンスを効かせやすくなります。KubeFedのデモ動画を参照したり、Katacodaを利用して KubeFedを体感 できますので、これらのWebページもご参照ください。 Using KubeFed to Deploy Applications to OCP3 and OCP4 Clusters Quayの提供形態 2020年2月時点では下記の2種類です。 Red Hat Quay.io (SaaS版のQuay) Red Hat Quay (オンプレミス版のQuay) この他に、Red Hat Quay.ioとRed Hat Quayのソースコードをベースにオープンソース化した Project Quay があります。元々Quayはプロプライエタリ・ソフトウェアでしたが、2019年11月に オープンソース化したProject Quayをリリース しています。今後はProject QuayがRed Hat Quay.ioとRed Hat Quayのアップストリームになります。 SaaS版のQuay.ioについては、アカウントを作成して利用プランを選択するだけで使ってみることができます。利用プランは複数ありますが、どのプランでも30日間の無料トライアルを利用でき、かつ、パブリックなリポジトリは無制限に利用できます。無料期間が終了した後も、現時点では 15USドル/1ヶ月~ で利用できますので最初の利用ハードルは比較的低くなっています。 quay.io Operatorを利用したRed Hat Quayのインストールの前準備 オンプレミス版のRed Hat Quayをインストールするには、下記の手順のいずれかを実行します。いずれの手順でも、Red Hatが提供しているQuayのコンテナイメージをダウンロードしてデプロイします。 Deploy Red Hat Quay - Basic (Quayのテスト用デプロイ) Deploy Red Hat Quay on OpenShift Deploy Red Hat Quay on OpenShift with Quay Setup Operator Deploy Red Hat Quay - High Availability (オンプレやパブリッククラウド上に高可用性なQuay環境をデプロイ) ここではOpenShift 4のOperatorを利用したRed Hat Quayのインストール手順を紹介していきます。2020年2月時点の最新バージョンであるOpenShift 4.3の利用をここでは想定します。Red Hat Quayは、2019年12月にリリースされた3.2からOperatorを利用したインストール手順を正式にサポートするようになりました。 www.redhat.com Operatorにより、Red Hat Quayをとても簡単にOpenShift 4の環境上にインストールできるようになっています。Operatorによるインストールには、前提条件が2つあります。 OpenShiftクラスタの管理権限(cluster-adminユーザなどの権限)を利用 Red Hat Quayのコンテナイメージを取得するための 認証情報 認証情報を取得した後は、下記のようなコマンドを実行してQuayをインストールするプロジェクト(この例ではquay-enterprise)上にSecretを作成します。 $ cat << EOF > redhat-quay-pull-secret.yaml apiVersion: v1 kind: Secret metadata: name: redhat-pull-secret data: .dockerconfigjson: XXXXXXXXXX type: kubernetes.io/dockerconfigjson EOF $ oc login -u kubeadmin <OpenShift 4環境のAPI URL> $ oc new-project quay-enterprise $ oc create -f redhat-quay-pull-secret.yaml secret/redhat-pull-secret created これで前準備は完了です。 Operatorを利用したRed Hat Quayのインストール (GUI) quay-enterpriseプロジェクト上で、OpenShift 4のOperator HubからQuayのOperatorを選択してインストールします。インストール時に選択するものは、全てデフォルト値のままで「Subscribe」をクリックします。 これにより、Quay OperatorがPodとしてセットアップされます。quay-operator-xxxxという名前のPodがRunning/Ready状態になればOperatorのセットアップは完了です。このOperatorからQuay環境を自動作成・削除できるようになります。「Installed Operators」->「Quay」->「QuayEcosystem」->「Create QuayEcosystem」と選択していき、下記のようなYAMLファイルを入力して「Create」をクリックすればQuay環境が自動的に作成されます。このYAMLファイルではQuayや後述するClairのコンテナイメージをPullするためのSecretとして、上記手順で作成した「redhat-pull-secret」Secretを指定しています。これにより、example-quayecosystem-xxxxという名前のQuay関連のPod郡がquay-enterpriseプロジェクト上に作成されていきます。 apiVersion: redhatcop.redhat.io/v1alpha1 kind: QuayEcosystem metadata: name: example-quayecosystem spec: quay: imagePullSecretName: redhat-pull-secret enableRepoMirroring: true clair: enabled: true imagePullSecretName: redhat-pull-secret もし、いずれかのPodがNot ReadyやCrashLoopBackOffなどの状態になっていてQuayのインストールが進まない場合は、一度作成したQuayEcosystemを削除して、再作成してみてください。その場合は、作成したQuayEcosystemの名前をクリックして、「Actions」->「Delete QuayEcosystem」から削除ができます。このとき、quay-operator-xxxxというPodによりQuay関連のPod郡が自動的に削除されます。 下記のようにexample-quayecosystem-xxxxというPodが全てRunning/Ready状態になり、example-quayecosystem-quayというRouteが作成された状態になれば、Quayのインストールは完了です。Quay Operatorにより、PostgreSQL(QuayとClairのメタデータ格納用)、Redis(Quayのチュートリアルやライブビルドログ格納用)、Quay、ClairのPodが自動的に作成されていることを確認できます。 Operatorを利用したRed Hat Quayのインストール (CLI) CLIを使用してOperator及びRed Hat Quayをインストールする場合は、下記のコマンドを実行します。QuayのOperator GroupとSubscriptionを作成すると、Quay Operatorがデプロイされます。Quay Operatorを利用して quayecosystem というリソースを作成することでQuay関連のPod郡がデプロイされます。 $ cat << EOF > quay-operatorgroup.yaml apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: generateName: "quay-enterprise-" namespace: quay-enterprise spec: targetNamespaces: - quay-enterprise EOF $ oc create -f quay-operatorgroup.yaml $ cat << EOF > quay-subscription.yaml apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: generateName: "quay-operator-" namespace: quay-enterprise spec: channel: stable installPlanApproval: Automatic name: quay source: community-operators sourceNamespace: openshift-marketplace EOF $ oc create -f quay-subscription.yaml $ cat << EOF > quay-clair-ecosystem.yaml apiVersion: redhatcop.redhat.io/v1alpha1 kind: QuayEcosystem metadata: name: example-quayecosystem namespace: quay-enterprise spec: quay: imagePullSecretName: redhat-pull-secret enableRepoMirroring: true clair: enabled: true imagePullSecretName: redhat-pull-secret EOF $ oc create -f quay-clair-ecosystem.yaml (参考) 4.1.2. CLI を使用した OperatorHub からのインストール Operatorを利用したQuayの削除、及び、クラスターからQuay Operatorを削除する場合は、下記のようなコマンドを実行します。 $ oc delete quayecosystem/example-quayecosystem -n quay-enterprise <- "oc get quayecosystem"で取得したQuay Ecosystemの名前を指定 $ oc delete subscription/quay-operator-xxxxx -n quay-enterprise <- "oc get subscription"で取得したQuay Subscriptionの名前を指定 $ oc delete clusterserviceversion/quay.v1.0.1 -n quay-enterprise <- "oc get clusterserviceversion"で取得したQuayのCluster Service Versionの名前を指定 (参考) 5.2. CLI の使用によるクラスターからの Operator の削除 Red Hat Quayの使用 上記のRouteで表示されているURLにアクセスして、Red Hat Quayにログインします。デフォルトのログインアカウントは Username: quay, Password: password です。 イメージリポジトリの作成とPush/Pullを試してみたい場合は、上部の「TUTORIAL」から指定される手順を実施してみるといいでしょう。ただし、TUTORIALで指定される手順はroot権限を必要とするDockerの利用を前提としていますので、非管理ユーザで試して見る場合は、下記のようなPodmanを使う手順を試してみることもできます。やっていることは単純で、busyboxという名前のコンテナイメージをPullしてきてカスタムリポジトリにPushしているだけです。 $ podman login --tls-verify=false -u=quay -p=password example-quayecosystem-quay-XXXXXX.net $ podman pull busybox $ podman images $ podman tag <busyboxイメージのContainer ID> example-quayecosystem-quay-XXXXXX.net/quay/testbusybox <- QuayのURLの後にユーザ名(quay)と作成するリポジトリ名(testbusybox)を指定 $ podman push --tls-verify=false example-quayecosystem-quay-XXXXXX.net/quay/testbusybox この手順によりtestbusyboxという名前のリポジトリが作成されることを確認できます。このリポジトリからイメージをPullする場合は下記のようなコマンドを実行します。 $ podman pull --tls-verify=false example-quayecosystem-quay-XXXXXX.net/quay/testbusybox こうしたリポジトリに対するPush/PullのログをQuayのWebコンソールから確認できます。また、不要になったリポジトリは、リポジトリの設定メニューから削除できます。 カスタムリポジトリに対するコンテナイメージのPushやPullはSaaS版のQuay.ioでもできますが、オンプレミス版のQuayだと外部レジストリを指定したリポジトリのミラーリングを自動実行できるようになります。ミラーリングには skopeo というレジストリに対するイメージの情報取得・コピー・削除機能を持つソフトウェアを利用しています。設定手順は次の製品ドキュメントに沿って行いますが、基本的には以下の流れです。 Chapter 7. Repository Mirroring in Red Hat Quay ミラーリングに利用する空リポジトリを作成 リポジトリの設定画面から、上記リポジトリのRepository Stateを「Mirror」に変更 上記リポジトリに書き込み権限を持つ、ミラーリング用のロボットアカウントを作成 リポジトリのミラーリング設定画面から、ミラーリング対象のリポジトリのURL/認証情報、同期間隔などを設定して同期開始 同期間隔の単位は、秒/分/時間/日/週のいずれかを指定できます。下記の例だとDocker Hubにあるlatestタグがついたbusyboxコンテナイメージを、mirror-busyboxというリポジトリに30秒間隔で同期を取る設定にしています。 リポジトリのミラーリングログも保存されます。これもコンテナイメージのPush/Pullの場合と同様にWebコンソールから確認できます。ミラーリング機能により複数拠点にあるコンテナイメージレジストリの同期が取りやすくなります。 また、リポジトリの設定画面から、リポジトリに対する変更があったときの自動通知も設定できます。リポジトリへのPush、ミラーリング、パッケージの脆弱性発見などのイベント発生時に、Quayユーザアカウントへの通知、Slack、HipChatなどを利用した通知を設定できます。 (参考) Chapter 5. Repository Notifications Clairによるコンテナイメージ脆弱性の静的解析 Quay.ioとQuayではコンテナイメージ脆弱性の静的解析に Clair というソフトウェアを利用しています。Clairは公開されている脆弱性情報を定期的に取得し、コンテナイメージ脆弱性の静的解析を行います。Clairが取得する脆弱性情報は Red HatやNISTなどが公開しているもの であり、これらの脆弱性情報に対応する種類のコンテナイメージを解析できます。なお、公開している脆弱性情報に該当するかを評価・報告するための言語仕様として OVAL というものがあり、この仕様に準拠した形式で実装されているOVALファイルを脆弱性検査に利用します。例えばRed HatはRHELの脆弱性検査に利用する OVALファイルを公開 していますが、こうしたファイルをRHEL7やRHEL8のコンテナイメージの脆弱性解析に利用しています。ClairはRHELなどのコンテナイメージをPushすると、自動的にスキャンを実行してどのような脆弱性があるかを報告します。 Clairはデフォルトでは500分に1回の頻度で脆弱性検査に利用する内部データベースを更新しますが、この更新頻度を変更することもできます。その場合は、QuayEcosystemを作成するときに指定するYAMLファイルに updateInterval を追加します。下記の例だと60分に1回の更新頻度を指定しています。 apiVersion: redhatcop.redhat.io/v1alpha1 kind: QuayEcosystem metadata: name: example-quayecosystem spec: quay: imagePullSecretName: redhat-pull-secret enableRepoMirroring: true clair: enabled: true imagePullSecretName: redhat-pull-secret updateInterval: "60m" さらに、Clairを利用してOpenShift環境全体のコンテナイメージの脆弱性の静的解析を行うことができます。この機能を利用する場合は、 Container Security Operator(CSO) をOperator Hubからインストールします。CSOをインストールする場合もデフォルト値から変更しなくてOKです。 CLIを使用してCSOをインストールする場合は、下記のコマンドを実行します。 $ cat << EOF > container-security-subscription.yaml apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: generateName: "container-security-operator-" namespace: openshift-operators spec: channel: alpha installPlanApproval: Automatic name: container-security-operator source: community-operators sourceNamespace: openshift-marketplace EOF $ oc create -f container-security-subscription.yaml CSOがインストールされると、container-security-operator-xxxxというPodがopenshift-operatorsというプロジェクトに作成されます。このPodがKubernetes APIを利用して、Kubernetes/OpenShift環境にあるコンテナイメージの脆弱性を検査します。検査結果の概要はダッシュボードから確認できます。検知した脆弱性がどのくらいあるかを可視化します。 今回の場合だと、表示されているパッケージ名に、OpenShift 4やQuayをインストールする時にPullしてきたQuay.ioにあるRed Hatリポジトリのイメージマニフェストのリンクが貼られていますが、ほとんどの方はQuay.ioのRed Hatのリポジトリにアクセスするためのアカウントを持っていないので、マニフェストが見つかりませんというメッセージしかおそらく表示されないと思います。そこで、脆弱性の情報はYAML形式で確認します。「1 namespaces」といったリンクをクリックすると、ImageManifestVulnという脆弱性情報を持ったリソースが確認できますので、そちらからYAML形式で脆弱性情報を確認します。 ImageManifestVulnの情報はocコマンドでも表示できます。その場合は oc get ImageManifestVuln を実行します。これで脆弱性情報をCLIからでも確認できます。こうして確認した脆弱性情報をもとに、コンテナイメージを随時更新・再デプロイすることで、既知の脆弱性を放置する危険性を少なくできます。 $ oc get ImageManifestVuln --all-namespaces NAMESPACE NAME AGE quay-enterprise sha256.5073e39508248811c10398ce1dbb59d753ff47f690eb97e7938b80e13c628ab7 17m quay-enterprise sha256.93b911c720930a49d327f8f97c38dcd510db0692251f139ed709cb83fe00f903 17m quay-enterprise sha256.af7de1465d9992b8c5756723f75190d80ca8b18a08a0be7971792668120ee92d 17m $ oc get ImageManifestVuln/sha256.5073e39508248811c10398ce1dbb59d753ff47f690eb97e7938b80e13c628ab7 -o yaml -n quay-enterprise apiVersion: secscan.quay.redhat.com/v1alpha1 kind: ImageManifestVuln metadata: creationTimestamp: "2020-02-15T08:25:46Z" generation: 1 labels: quay-enterprise/example-quayecosystem-clair-556ff76bd6-g8zs2: "true" name: sha256.5073e39508248811c10398ce1dbb59d753ff47f690eb97e7938b80e13c628ab7 namespace: quay-enterprise resourceVersion: "124174" selfLink: /apis/secscan.quay.redhat.com/v1alpha1/namespaces/quay-enterprise/imagemanifestvulns/sha256.5073e39508248811c10398ce1dbb59d753ff47f690eb97e7938b80e13c628ab7 uid: a84d2fb0-8991-4ac0-83e7-ee86cbd07334 spec: features: - name: perl-Git namespaceName: centos:7 version: 1.8.3.1-20.el7 versionformat: rpm vulnerabilities: - description: 'Git is a distributed revision control system with a decentralized architecture. As opposed to centralized version control systems with a client-server model, Git ensures that each working copy of a Git repository is an exact copy with complete revision history. This not only allows the user to work on and contribute to projects without the need to have permission to push the changes to their official repositories, but also makes it possible for the user to work with no network connection. Security Fix(es): * git: Remote code execution in recursive clones with nested submodules (CVE-2019-1387) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.' fixedby: 0:1.8.3.1-21.el7_7 link: https://access.redhat.com/errata/RHSA-2020:0124 name: RHSA-2020:0124 namespaceName: centos:7 severity: High - name: sqlite namespaceName: centos:7 version: 3.7.17-8.el7 versionformat: rpm vulnerabilities: - description: 'SQLite is a C library that implements an SQL database engine. A large subset of SQL92 is supported. A complete database is stored in a single disk file. The API is designed for convenience and ease of use. Applications that link against SQLite can enjoy the power and flexibility of an SQL database without the administrative hassles of supporting a separate database server. Security Fix(es): * sqlite: fts3: improve shadow table corruption detection (CVE-2019-13734) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.' fixedby: 0:3.7.17-8.el7_7.1 link: https://access.redhat.com/errata/RHSA-2020:0227 name: RHSA-2020:0227 namespaceName: centos:7 severity: High - name: git namespaceName: centos:7 version: 1.8.3.1-20.el7 versionformat: rpm vulnerabilities: - description: 'Git is a distributed revision control system with a decentralized architecture. As opposed to centralized version control systems with a client-server model, Git ensures that each working copy of a Git repository is an exact copy with complete revision history. This not only allows the user to work on and contribute to projects without the need to have permission to push the changes to their official repositories, but also makes it possible for the user to work with no network connection. Security Fix(es): * git: Remote code execution in recursive clones with nested submodules (CVE-2019-1387) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.' fixedby: 0:1.8.3.1-21.el7_7 link: https://access.redhat.com/errata/RHSA-2020:0124 name: RHSA-2020:0124 namespaceName: centos:7 severity: High image: quay.io/redhat/clair-jwt manifest: sha256:5073e39508248811c10398ce1dbb59d753ff47f690eb97e7938b80e13c628ab7 namespaceName: centos:7 status: affectedPods: quay-enterprise/example-quayecosystem-clair-556ff76bd6-g8zs2: - cri-o://56c8f9dc4a68d3b02875b214721a0536d5f683d8c29ebf4382e6157168450626 fixableCount: 3 highCount: 3 highestSeverity: High lastUpdate: 2020-02-15 08:25:46.564070808 +0000 UTC まとめ QuayとClairの概要や、Operatorによる基本的なセットアップ手順と利用手順を一通り紹介してきました。より詳細な情報については下記の参考情報もご参照ください。 References Red Hat QuayとProject Quayの参考情報の一覧です。 Product Documentation for Red Hat Quay 3 - Red Hat Customer Portal Red Hat Quay Life Cycle Policy - Red Hat Customer Portal Red Hat Quay Support Policy - Red Hat Customer Portal Quay Enterprise 3.x Tested Integrations - Red Hat Customer Portal https://www.projectquay.io

Happy Valentine's Day! Red Hatの久保田です。 さて、オリンピックを前にリモートワークを準備していた皆様の中には、この数週間で急遽リモートワークに切り替えた方も多いのではないでしょうか。 Red Hatではリモートで働く社員が多く、日本からアメリカの組織で働く社員もいますし、電話会議をすると自宅の書斎やリビングから参加する人も多いです。ペットの声が聞こえることもよくあります。 （先日は会議相手の背景にプールが見えました。） 私的ldapsearchによると、今Remoteとして登録している社員数は世界で7000人以上。 日本から世界のオフィスにリモートで働いているのは100人弱のようです。 今回はリモートワークをする際のマイルール、セキュリティとオープンソースを中心に翻訳してみました。 ティーポットと美味しい紅茶の葉、クッキーを用意して読んでみてください。 ブログ著者の紹介：　マイク・バーゼル 2016年8月からRed HatのCTOオフィスに在籍し、セキュリティ、仮想化、ネットワークなどに従事。 ソフトウェアエンジニアリングのトレーニングの後、分散システムとセキュリティに特化する。この数年はアーキテクチャと技術ストラテジーに携わる。Red Hatではセキュリティストラテジー、内外向けの活動、リーダーシップを担当。 Enarxプロジェクトの共同創立者の一人。北米、ヨーロッパ、APACの業界イベントで講演を行う。 興味はLinux、コンフィデンシャル・コンピューティング、オープンソースソフトウェア、セキュリティ、分散システム、ブロックチェーン、NFV、SDN、仮想化 ケンブリッジ大学修士号、オープン大学のMBA aliceevebob.com イギリス人の語る、リモートワークのコツとは？ aliceevebob.com ブラウザがHTTPSでないサイトに警告を出すようになり、この”S"の部分に気付く方も多くなったのではないでしょうか。 コンフィデンシャルコンピューティングにも注目が集まっています。 aliceevebob.com オープンソースのセキュリティってどうなの？ 経済学も交えて、プロジェクトとプロダクト、そのセキュリティに関しての記事です。 aliceevebob.com ハッカーもクラッカーも、オープンソースを使います。 オープンソースはどんな人にも”オープン”です。 奥が深く考えさせられます。 aliceevebob.com トラスト：信用、信頼はセキュリティでは鍵です。 オープンソースにおける信頼性とはどうなっているのか。 aliceevebob.com オープンソースはその名の通り、オープンです。 ではパーフェクトかというと、そうでもない。 でもそこに近づけることはできます。 それにはさらにたくさんの方の参加が必要です。 さて、ブログ記事ではないのですが、Red HatではCO.LABというプロジェクトがあります。 www.redhat.com オープンソースを次の世代に、特に女性にも貢献してもらおうというのものです。 今はUSだけの活動ですが、日本でも広めて行けたらと思っておりますのでよろしくお願いいたします！

この記事は、Quarkus.io のブログ記事、 Quarkus 1.2.0.Final released - GraalVM 19.3.1 support, Metrics, Cache extension, and more の翻訳記事です。 前回のQuarkusの修正から1ヶ月が経過し、みなさんも頻繁なリリースにも慣れてきましたので、1.2.0.Final がリリースされました。私たちは多くの新しい機能を提供するために努力してきました:GraalVM 19.3 .1のサポートがついにされ、すべてを簡単にキャッシュするために新しいキャッシュ拡張機能を追加し、いくつかの拡張機能のためのデフォルト計量機能を追加し、私たちのHashiCorp Vaultサポートが大幅に改善するなど多くのものを提供しました。 既存のアプリケーションを移行したいとお考えですか？ここに 1.2.0.Finalの移行ガイドがあります 。 このすべてについてさらに学ぶことに興奮していますか？これらの新機能について詳しく説明します。 何が新しいの？ GraalVM 19.3 .1のサポート 1.2.0.Finalは3種類のGraalVMをサポートしています。 GraalVM 19.2 .1-JDK8　(これは1.3に廃止されます。) GraalVM 19.3 .1-JDK8 GraalVM 19.3 .1-JDK11 (JDK11です!) Red HatのOpenJDKチームとGraalVMチームと一緒に、私たちはついに19.3ブランチで遭遇したすべての問題に打ち勝ち、19.3.1で我々に必要な最新の修正を提供しました。 最後に、ネイティブの実行可能ファイルを構築する場合でも、みなさんはJDK11の使用を開始できます。ただし、JDK11向けのGraalVMはまだテクニカルプレビューの段階です。 19.3 .0はサポートされていません。19.2.1または19.3.1のいずれかが必要です。 要約すると、Quarkusでは次のように使用できます。 JVMモードのJDK 8, 11, 12, 13。JDK 14のサポートはQuarkus 1.3に予定されています。 ネイティブ実行可能ファイルを構築するためには JDK 8または11 キャッシュ拡張 まったく新しいCache拡張機能では、CDI Beanメソッドの戻り値をキャッシュすることができます。Caffeineをベースにしており、それを駆動するための一連の注釈が付いています。 簡単に言うと、次のようになります。 @ApplicationScoped public class CachedBean { @CacheResult(cacheName = "foo") public MyObject load(MyKey key) // Call expensive service here. } @CacheInvalidate(cacheName = "foo") public void invalidate(MyKey key) { } @CacheInvalidateAll(cacheName = "foo") public void invalidateAll() { } } もっと知りたいですか？こちらに ガイド があります。 計量機能 私たちはQuarkusの可観測性を継続的に改善し、デフォルトの健全性調査の追加に取り組んだ後、デフォルトの計量機能の追加に取り組んでいます。 1.2.0では、Agroal(データベース接続プール)とHibernate ORMの計量機能を追加しました。 Quarkusに貢献するための出発点を探していて、特定の拡張のための計量機能を必要としているなら、これは良い最初の貢献になるでしょう。 Vaultの改良 HashiCorp Vaultサポートにいくつかの改良を加えました。 Vault Transit Secret Engineがサポートされ、Vaultを「サービスとしての暗号化 (encryption as a service)」に使用できるようになりました。必要な情報はすべて 専用のガイド に記載されています。 複数のKVパスのサポートが追加されました。 SmallRye Fault Tolerance 4.x この ブログ記事 （ 日本語 ）で詳しく説明しているように、私たちはまったく新しいMicroProfile Fault Tolerance実装を用意しました。 以前よりも高速になるはずです(1.3に向けてさらに改良が進められています)ので、試してみて問題が発生したら報告してください。 Hibernate ORM 自動関連付け管理を使用不可にしました。 Hibernate ORMの拡張機能には、関連付けを自動的に管理する機能があります。関連付けの一方の端に要素を追加すると、もう一方の端に要素が自動的に追加されます。 これは非常に実用的ですが、状況によってはうまく機能しない場合があり、すぐに扱いにくくなることがあります。Quarkusで無効にすることにしました。 チューニングの詳細 application.properties から次の設定を行えます。: 物理的な命名戦略 暗黙の命名戦略 識別子をすべて引用符で囲む必要がある場合 すべてのHibernate ORM構成プロパティーについては、 マニュアル を参照してください。 Hibernate Validatorのローカライズ 複数のロケールをサポートするようにQuarkusアプリケーションを構成する場合、REST呼び出しのコンテキストでBeanまたはメソッドを検証すると、Hibernate ValidatorがAccept-Languageヘッダーから使用するロケールを自動的に解決するようになりました。 詳細については、 検証ガイド を参照してください。 ArCにおけるトランザクション監視のサポート 私たちのCDI実装であるArCは現在、トランザクション監視 @Observes(during = TransactionPhase.AFTER_SUCCESS) をサポートしています。 さらに Qute メール拡張機能を使ってメールを送るときにQuteテンプレートエンジンを使うことができるようになりました。 現在、UBIをベースイメージとして使用 私たちはしばらくの間、JDKベースのDockerfileのベースイメージとしてAlpineを使用しました。JDKとネイティブDockerfile用に一貫してUBIイメージを使用するようになりました。 さらに... カテゴリ・レベルで各ハンドラのロギング構成を上書きできるようになりました。 Hibernate Search 6.0.0 beta3にアップグレードしました。 従来のMongo-java-driverアーティファクトの代わりに、Mongodb-driver-syncを使用するようになりました。 完全な変更ログ 1.2.0.CR1 と 1.2.0.Final の完全な変更ログはGitHubで入手できます。 ADOPTERS.md Quarkusの使用に関する情報を共有するために、リポジトリのルートに ADOPTERS.mdファイル を追加しました。 Quarkusを使用していて、私たちのブログでインタビューを受けたい場合、または単にこのファイルに追加したい場合は、私たちにご連絡ください。 貢献者 Quarkusには現在 215人の貢献者 がいます。皆様、本当にありがとうございました。 特に1.2.0リリースについてはみなさんのおかげです。 Akito Kidani, Alex Soto, Alexander Zimmermann, Alexey Loubyansky, Anatoly Sablin, Andreas Eberle, Andreas Paschwitz, Andrew Guibert, Andy Damevin, Arne Mejlholm, Bruno Devaux, Clement Escoffier, Damien, David M. Lloyd, David Walluck, Dennis Baerten, Emmanuel Bernard, George Gastaldi, Georgios Andrianakis, Gordon Hutchison, Grzegorz Piwowarek, Guillaume Smet, Gunnar Morling, Gwenneg Lepage, Gytis Trikleris, Harald Reinmueller, Ian Wormsbecker, Ioannis Canellos, Irena Kezic, Jaikiran Pai, Jan Martiska, Jason T. Greene, Johannes, Justin Lee, Ladislav Thon, Loïc Mathieu, Manyanda Chitimbo, Marcel Overdijk, Mark Little, Martin Kouba, Matej Novotny, Matt Berteaux, Matthias Harter, Max Rydahl Andersen, Michael J. Simons, Michal Szynkiewicz, Nayden Gochev, Pavol Loffay, Pedro Igor, Peter Palaga, Rohan Maity, Romain Quinio, Rostislav Svoboda, Sanne Grinovero, Sergey Beryozkin, Stuart Douglas, Stéphane Épardaud, Tobias, Vincent Sevel, Vinícius Ferraz Campos Florentino, x80486 and Yoann Rodière. 参加しよう 私たちはあなたのフィードバックをとても大切にしていますので、バグを報告し、改善を依頼してください...一緒に何か素晴らしいものを作りましょう! Quarkusのユーザーや好奇心の強い人は、恥ずかしがらずに歓迎コミュニティに参加してください。 GitHub にフィードバックを提供する; コードを作成して PRを行う ; Zulip や メーリングリスト で議論する; なにか質問があれば Stack Overflow で投稿してください。

この記事は、Quarkus.io のブログ記事、 New fault tolerance implementation in Quarkus の翻訳記事です。 最初のリリースから、 QuarkusはMicroProfile Fault Toleranceで耐障害性アプリケーションを作成することができます。 この機能を提供するためにSmallRye Fault Toleranceを使用します。 SmallRye Fault Toleranceが生まれた当時、 Hystrix はまだ存在しており、実装の中核として選ばれました。その選択は最適ではないことがわかりました。ライブラリ自体はもう開発されていません。さらに、MicroProfile Fault Tolerance仕様の変更により、Hystrixを使った解決策で仕様を満たすことは不可能になりました。私たちはHystrixを排除する必要があるという結論に至りました。 2019年の終わりに少し時間がありました簡単に言うとここです。Quarkus 1.2 .0.CR1には、Hystrixを独自の機能に置き換えた、まったく新しいSmallRye Fault Toleranceバージョン4.0 .0が付属しています。 新しい実装は、ゼロから作成した機能に基づいていることに注意してください。すべてのテストに合格したことを確認し、さらに多くのテストを追加しましたが、まだ実戦でテストは行われていません。 そのため、私たちの訴えとして : 新しいバージョンのQuarkusで拡張機能を試してみて 、あなたにとってどのように動作するかを教えてください。 詳細に興味があれば、 SmallRyeのブログ記事 を参照してください。

この記事は、Quarkus.io のブログ記事、 Delay in GraalVM 19.3 support - planned for Quarkus 1.2 - here is why の翻訳記事です。 Quarkus 1.1.0.CR1で待望の機能のひとつがGraalVM 19.3のサポートです。GraalVM 19.3は非常に多くの点で変更がありますが(JDK11プレビューなど)、QuarkusとGraalVMの緊密な統合のおかげで、GraalVM 19.2と19.3を同時にサポートすることができなかった私たちにとっては、全てか、ゼロか、のアップデートでした。 QuarkusをGraalVM 19.3に移植する間に、いくつかの再発した不具合を経験しましたが、その中にはQuarkusが適切に動作していない(私たちはそれらを修理済)、あるいはGraalVMの再発した不具合(私たちはGraalVMチームと協力してそれらを修正中)によるものもありました。GraalVMの次のマイクロバグフィックスリリースは1月中旬に予定されているため、Quarkusから代替案を作成することで回避策を実行する必要がありました。 例え、良くはなかったとしても、最終的な結果は十分にしっかりしていたので、GraalVM 19.3サポート付きでCR1を出荷することにしました。 しかし、私たちの1.1.0.FinalはGraalVM 19.2に戻っています。これは難しい決断でした。特に、1.1に向けて準備するために投資されたすべての作業を考えれば、なおさらです。ですから、このバージョンを戻す理由は何なのでしょうか? 私たちは約束を破りたくない Quarkusが約束していることの1つは、エコシステムはどのJVMでもGraalVMネイティブイメージ実行可能ファイルと同様にうまく動作するということです。また、面倒な作業をしなくてもネイティブイメージを作成できることです。 多くの問題がこれから外れていました。 ランダムに発生する同時実行性の問題により、ネイティブ・イメージの作成が失敗することがありました。 Neo4Jの拡張機能と、より一般的なNeo4JドライバがGraalVM 19.3では動作しません : https://github.com/oracle/graal/issues/1995 Apache Camel Quarkusの統合テストのいくつかは、 https://github.com/oracle/graal/issues/1971 のためにネイティブイメージモードでは動作しなくなりました。私たちはこれと共存できたかもしれませんが、それはあなたのアプリケーションのどれにでも起こりうることを意味します。 これらの再発した不具合では、私たちはすでに囲いの上にいて、すでにいくつかの修正を行っていました(下記参照)。しかし、私たちはQuarkusの約束の核心である別のものを見つけました。 RSS(メモリ)使用率の回帰 1.1 .0.CR1のリリース後、起動時のRSS利用量が以前ほど良くないという報告を受けました。RSSは、プロセスの常駐サイズ、つまりプロセスが消費するすべてのメモリーを測定します。 我々の測定では、最初のリクエスト/レスポンスが提供された後、GraalVM 19.2を搭載したQuarkus 1.1は14MBでした。GraalVM 19.3では63MBになりました。Quarkusのメモリ消費量が重要な値であるため、取り消すボタンをクリックし、さらに時間をかけることにしました。 この問題を解決するために、QuarkusとGraalVMチームの間で調査が行われています。詳細については知りたい方は、 Quarkusの問題 とそれに 関連するGraalVMの問題 を参照してください。この記事の最後に行き着くとすぐに、GraalVM 19.3上で動くQuarkusへの道筋が解決されます。 それでどうする? まず、GraalVMインストールを次の1.1 .0.Final向けに19.2 .1にダウングレードする準備をしてください。 私たちの次のリリースではGraalVM 19.3のサポートを全速力で提供する予定です（おそらくGraalVM JDK11もサポートされるでしょう）。並行性の問題はGraalVMのマスターブランチではすでに修正されているので、私たちは低レベルの問題を扱うことができます。私たちの目標は、GraalVMチームがこれらの問題を理解して修正し、これらのすべてをGraalVM 19.3 .1にバックポートすることです。 しかし、もっと基本的に、私たちはそれが再び起こることを望んでいません:ゲームの後半でこれらを発見することは楽しくありません。これらの問題を早期に発見できるように、Quarkusエコシステム全体(コア拡張+quickstarts+Camel拡張+その他の外部拡張)がGraalVMのマスターブランチとうまく連携していることをチェックするいくつかのCIジョブをセットアップしています。これは、(GraalVM)マスタブランチ上の(Quarkus)マスタブランチ上の(Apache Camel Quarkus)マスタブランチとなり少し難解ですが、これが唯一の方法です。私たちはすでに、QuarkusのマスターブランチとGraalVMのマスターブランチでQuickStartの一式をテストするCIジョブを持っています。 また、このCIパイプラインにRSS使用量のチェックを追加する予定です。面白い話ですが、私たちはRSSをテストする別のCIのジョブを持っていましたが、そのレポートはNullPointerExceptionで失敗しています。🤦 私たちの慎重な姿勢と1ヶ月程度の遅れをあなたにご理解いただければ幸いです。 それまでの間、Quarkusの新バージョンには多くのエキサイティングな機能が搭載されているので、準備しておいてくださいね。

Red Hatでコンサルタントをしている織です。 こちらの記事 では、upstreamのKubernetesとMultusを使ってKVM環境上でMultusを検証しました。本記事では、IPI方式でAWS上に構築したOCP (OpenShift Container Platform) v4.3を使ってMultusを動かしてみます。 いきなりIPIと書きましたが、OpenShift v4では、環境構築の方法が大きく2種類あり、IPIはそのうちのひとつです。 IPI(Installer Provisioned Infrastructure)方式のインストール - ネットワーク、ロードバランサ、DNSレコード、仮想マシンインスタンス等、OpenShiftのインストールに必要なインフラのコンポーネントをインストーラが自動的に作成します。workerノードのオートスケールができるようになったりします。インフラをAPIで制御できる環境(例えばIaaS)上にOpenShiftクラスターを構築するときはこちらが便利です。 UPI(User Provisioned Infrastructure)方式のインストール - ネットワーク、ロードバランサ、DNSレコード、仮想マシンインスタンス等、OpenShiftのインストールに必要なインフラのコンポーネントは、あらかじめユーザーが自身で用意しておく必要があります。インストーラはその上にOpenShiftをインストールします。インフラをAPIで制御できない環境(例えばオンプレのベアメタル環境)や、IPIが作る構成だと要件に合わない場合、workerノードに(Red Hat CoreOSではなく)RHELを使いたい場合等はUPIを使います。 IPIでAWS上にOpenShiftクラスターを構築すると、 作成されるEC2インスタンスはNIC(ENI)を1個しか持たない ノードは異なるAZにまたがって分散配置 という構成になります。AWS上のOpenShiftでMultusを使う場合は、おそらくUPIで環境を作ることになるかと思うのですが、今回はIPIインストールで構築した環境に対して、少しカスタマイズしてMultusを使えるようにしました。特に深い理由はありません。 実際に行ったカスタマイズは以下です。 各ノードに対してNICを追加し、追加NICで通信するためのVPCサブネットを作成する 追加NICを使って異なるAZにいるworkerノード上のPodと通信できるようにstatic routeを設定する OpenShift v4では、クラスターに対する設定は全てOperator経由で行う作りになっています。例えばネットワーク周りの設定はCluster Network Operator(CNO)が司ります。Multusの設定をする際、 前の記事 ではNetworkAttachmentDefinitionのCustom Resourceを定義するmanifestを書いて kubectl create しましたが、OpenShiftではCNO経由でNetworkAttachmentDefinitionを作るよう、CNOに対して指示します。この辺りが本記事で一番言いたかったことなのですが、いろいろ余計なことを書いたので長くなってしまいました。ご容赦ください... OpenShiftクラスターの構築 AWS上にOpenShift v4.3.0[ 1 ]の環境を構築します。今回構築に使ったIPIという方式では、VPC、ELB、Route53のゾーン登録等、必要なAWSリソースは全て自動で作成し、その上でRHCOS(Red Hat CoreOS)を使ったEC2インスタンスを起動してOpenShiftクラスターを構成する、という一連の作業をコマンド一撃でやってくれます。 $ openshift-install create cluster AWS上でIPI方式でOpenShiftをインストールする手順の詳細は下記をご参照ください。 公式のインストール手順 [ 2 ] 猿でもできるOpenShift4インストール編 また、本検証ではやりませんでしたが、もしUPIを使ってインストールする場合は下記をご参照ください。 UPIでのベアメタル環境へのインストール手順 [ 3 ] OpenShiftを爆速でインストールしたいあなたへ Multusのために環境をカスタマイズ IPIインストールでAWSにOpenShiftクラスターを構築すると、下図のような構成になります(EC2インスタンスとVPCのプライベートネットワークのみ記載しています)。 IPIインストールでAWSにできるOpenShiftクラスター MultusでもうひとつNICを使うので、これをカスタマイズして、最終的に下図のようにしたいです。 Multusを動かしたい構成 そのために、 各AZにサブネットを追加し 追加サブネットごとに接続するENIを作成し 作成したENIを各workerノードにアタッチする というカスタマイズをします。 サブネットの追加 Multusで追加接続するためのサブネットを各リージョンに作成します。IPv4のアドレスブロックは、VPCのアドレスブロックから適当に切り出します。本環境では リージョン サブネット名 アドレスブロック ap-northeast-1a ocp43-multus-1a 10.0.201.0/24 ap-northeast-1c ocp43-multus-1c 10.0.202.0/24 ap-northeast-1d ocp43-multus-1d 10.0.203.0/24 を作成しました。AWS CLIでやるなら $ aws ec2 create-subnet --availability-zone ${az} --cidr-block ${cidr} --vpc-id ${vpc_id} $ aws ec2 create-tags --resources ${multus_subnet_id} --tags Key=Name,Value=${multus_subnet_name} みたいな感じです。 ENIの作成 各リージョンのworkerノードを追加したサブネットに接続するため、追加サブネットごとにENIを作成します。 今回は下記のIPアドレスを使うことにします。 サブネット プライマリのIPv4アドレス セカンダリのIPv4アドレス ocp43-multus-1a 10.0.201.11 10.0.201.21 〜 10.0.201.29 ocp43-multus-1c 10.0.202.11 10.0.202.21 〜 10.0.202.29 ocp43-multus-1d 10.0.203.11 10.0.203.21 〜 10.0.203.29 ipvlanでPodに付与するIPアドレスを、あらかじめENIのセカンダリプライベートIPv4アドレスとして列挙しておきます。 $ aws ec2 create-network-interface --subnet-id ${multus_subnet_id} \ --description "for multus, subnet: ${multu_subnet_name}, az:${az}" \ --private-ip-addresses Primary=true,PrivateIpAddress=${prefix}.11 \ Primary=false,PrivateIpAddress=${prefix}.21 \ Primary=false,PrivateIpAddress=${prefix}.22 \ Primary=false,PrivateIpAddress=${prefix}.23 \ Primary=false,PrivateIpAddress=${prefix}.24 \ Primary=false,PrivateIpAddress=${prefix}.25 \ Primary=false,PrivateIpAddress=${prefix}.26 \ Primary=false,PrivateIpAddress=${prefix}.27 \ Primary=false,PrivateIpAddress=${prefix}.28 \ Primary=false,PrivateIpAddress=${prefix}.29 $ aws ec2 create-tags --resources ${interface_id} --tags Key=Name,Value=eni-${multus_subnet_name} ENIをworkerノードへアタッチ 作成したENIを、各workerノードにアタッチします。 $ aws ec2 attach-network-interface --device-index 1 --instance-id ${instance_id} --network-interface-id ${interface_id} workerノードの確認 ENIをworkerノードにアタッチすると、workerノードのRHCOS(カーネル、ユーザーランドのコードはRHEL8と全く同じ[ 4 ])のカーネルが動的に追加インターフェースを ens4 として認識してくれます。workerノードでそのことを確認してみます。 OpenShift v4.xでmaster/workerノードに入ってOSコマンドを実行する方法は2つあります。 sshログインする - インストーラ( openshift-installer コマンド)実行ノードのssh-agentに鍵が登録されていれば、それをRHCOSのユーザー core のauthorized_keysに登録してくれます。 oc debug node を使用する - oc get node でノード名を調べ、 oc debug node/NODENAME を実行します。例: oc debug node/ip-10-0-133-117.ap-northeast-1.compute.internal どちらの方法で確認しても構いませんが、1.を実施するには、IPIインストールで作成したVPCサブネット上に外部からアクセスするための踏み台サーバが必要になります。 どちらかの方法でworkerノードに入って、インスタンスのインターフェースを確認します。 # ip addr show dev ens3 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000 link/ether 06:41:25:41:65:46 brd ff:ff:ff:ff:ff:ff inet 10.0.133.117/20 brd 10.0.143.255 scope global dynamic noprefixroute ens3 valid_lft 3255sec preferred_lft 3255sec inet6 fe80::b6d2:f22:84d1:e350/64 scope link noprefixroute valid_lft forever preferred_lft forever # ip addr show dev ens4 31: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000 link/ether 06:e5:2e:bf:58:3a brd ff:ff:ff:ff:ff:ff inet 10.0.201.11/24 brd 10.0.201.255 scope global dynamic noprefixroute ens4 valid_lft 2308sec preferred_lft 2308sec inet6 fe80::2af9:7855:12d6:f03d/64 scope link noprefixroute valid_lft forever preferred_lft forever ens3 が元々インスタンスが持っていたENIで、 ens4 が先ほど追加したENIです。 ルーティングテーブルを見てみます。 # ip route show default via 10.0.128.1 dev ens3 proto dhcp metric 100 default via 10.0.201.1 dev ens4 proto dhcp metric 101 10.0.128.0/20 dev ens3 proto kernel scope link src 10.0.140.137 metric 100 10.0.201.0/24 dev ens4 proto kernel scope link src 10.0.201.11 metric 101 10.128.0.0/14 dev tun0 scope link 172.30.0.0/16 dev tun0 ens4にもDHCPからもらったデフォルトゲートウェイが設定されていて気持ち悪いので、ens4ではDHCPでIPアドレスだけをつける(DHCPによるデフォルトゲートウェイとDNS設定をしない)ようにします。 # nmcli c s NAME UUID TYPE DEVICE Wired connection 1 e2fe62b6-e972-3d43-8023-320f467fec57 ethernet ens3 Wired connection 2 76577e5a-43d2-3f3d-b2d9-a93a067cf42c ethernet ens4 ens4のConnection nameである Wired connection 2 に対して、 ipv4.ignore-auto-dns と ipv4.ignore-auto-routes を有効化します。 # nmcli c m 'Wired connection 2' ipv4.ignore-auto-dns yes ipv4.ignore-auto-routes yes # sudo nmcli c d 'Wired connection 2' Connection 'Wired connection 2' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/2) # sudo nmcli c u 'Wired connection 2' Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3) これで、余分なデフォルトゲートウェイの設定が消えました。 # ip r default via 10.0.128.1 dev ens3 proto dhcp metric 100 10.0.128.0/20 dev ens3 proto kernel scope link src 10.0.140.137 metric 100 10.0.201.0/24 dev ens4 proto kernel scope link src 10.0.201.11 metric 101 10.128.0.0/14 dev tun0 scope link 172.30.0.0/16 dev tun0 各workerノードに対してこの操作を実施しておきます。 Multusのセットアップ 次にMultusの設定を行います。基本的に こちら の手順に従います。 まずおさらいですが、upstreamのKubernetes+Multusを使った前の記事では、 --- apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: ipvlan-conf spec: config: '{ "cniVersion": "0.3.1", "plugins": [ { "type": "ipvlan", "capabilities": { "ips": true }, "master": "eth1", "ipam": { "type": "static" } }, { "capabilities": { "mac": true }, "type": "tuning" } ] }' のようなmanifestを使ってNewtorkAttachmentDefinitionのCustom Resourceを作成しました。 一方OpenShift v4.xでは、CNIの設定は全て CNO (Cluster Network Operator) [ 5 ]が司る仕組みになっています。したがいまして、CNOに対してNetworkAttachmentDefinitionを作成してもらうよう指示する必要があります。具体的には、 $ oc edit networks.operator.openshift.io cluster を実行し、 spec.additionalNetworks の中に、NetworkAttachmentDefinitionのCustom Resourceで設定する内容を記載します。本記事の検証では spec: additionalNetworks: - name: network-ipvlan type: Raw rawCNIConfig: '{ "cniVersion": "0.3.1", "type": "ipvlan", "mode": "l2", "capabilities": {"ips": true}, "master": "ens4", "ipam": { "type": "static", "routes": [ {"dst": "10.0.202.0/24", "gw": "10.0.201.1"}, {"dst": "10.0.203.0/24", "gw": "10.0.201.1"} ] } }' のような内容を記載しました[ 6 ]。 この内容は、 ap-northeast-1a リージョン(追加サブネットのIPv4アドレスブロックが 10.0.201.0/24 )のworkerノードにPodをデプロイしたい場合の設定です。static routeの設定は、デプロイ先のworkerノードがいるリージョンごとに変える必要がありますのでご注意ください。 上記 oc edit networks.operator.openshift.io cluster で編集した内容は、 oc patch を使って oc patch networks.operator.openshift.io cluster --type merge -p '{"spec": {"additionalNetworks": [{"name": "network-ipvlan", "type": "Raw", "rawCNIConfig": "{\"cniVersion\": \"0.3.1\", \"type\": \"ipvlan\", \"mode\": \"l2\", \"capabilities\": { \"ips\": true }, \"master\": \"ens4\", \"mode\": \"l2\", \"capabilities\": { \"ips\": true }, \"ipam\": {\"type\": \"static\", \"routes\": [{ \"dst\": \"10.0.202.0/24\", \"gw\": \"10.0.201.1\" }, { \"dst\": \"10.0.203.0/24\", \"gw\": \"10.0.201.1\" }]}}"}]}}' もしくは oc patch networks.operator.openshift.io cluster --type json -p ' [{ "op": "add", "path": "/spec/additionalNetworks", "value": [] },{ "op": "add", "path": "/spec/additionalNetworks/0", "value": { name: "network-ipvlan", type: "Raw", rawCNIConfig: "{ \"cniVersion\": \"0.3.1\", \"type\": \"ipvlan\", \"mode\": \"l2\", \"capabilities\": { \"ips\": true }, \"master\": \"ens4\", \"ipam\": { \"type\": \"static\", \"routes\": [ { \"dst\": \"10.0.202.0/24\", \"gw\": \"10.0.201.1\" }, { \"dst\": \"10.0.203.0/24\", \"gw\": \"10.0.201.1\" } ] } }" } } ]' のように反映させることもできます。 CNOの設定変更が終わったら、 oc get net-attach-def を実行し、作成したNetworkAttachmentDefinitionの内容を確認します。 $ oc get net-attach-def network-ipvlan -o yaml apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: creationTimestamp: "2020-01-24T14:57:36Z" generation: 1 name: network-ipvlan <snip> spec: config: '{"cniVersion": "0.3.1", "type": "ipvlan", "mode": "l2", "capabilities": { "ips": true }, "master": "ens4", "mode": "l2", "capabilities": { "ips": true }, "ipam": {"type": "static", "routes": [{ "dst": "10.0.202.0/24", "gw": "10.0.201.1" }, { "dst": "10.0.203.0/24", "gw": "10.0.201.1" }]}}' Podのデプロイ 1つ目のPodのデプロイ 本検証では、下記のような設定のPodをデプロイします。 ipvlanでホストのens4経由で追加サブネットに接続する Podのデフォルトゲートウェイは、デフォルトCNIプラグインであるOpenShift-SDN側(ens3で接続している、IPIインストーラが作成したサブネット)にする ipvlanで接続した追加サブネット経由でPod間通信ができるよう、static routeを設定する まず、ap-northeast-1aのAZにいるworkerノードにデプロイすることを考えます。準備として、各ノードがどのAZにいるかを確認します。 $ aws ec2 describe-instances --filter Name=vpc-id,Values=${vpc_id} | jq -r '.Reservations[] | .Instances[] | [.PrivateDnsName, (.Tags[] | select(.Key == "Name").Value)] | @text' ["ip-10-0-158-197.ap-northeast-1.compute.internal","ocp43-9ld5l-worker-ap-northeast-1c-cphxt"] ["ip-10-0-149-79.ap-northeast-1.compute.internal","ocp43-9ld5l-master-1"] ["ip-10-0-143-118.ap-northeast-1.compute.internal","ocp43-9ld5l-master-0"] ["ip-10-0-133-117.ap-northeast-1.compute.internal","ocp43-9ld5l-worker-ap-northeast-1a-vcnxn"] ["ip-10-0-167-226.ap-northeast-1.compute.internal","ocp43-9ld5l-master-2"] ["ip-10-0-162-156.ap-northeast-1.compute.internal","ocp43-9ld5l-worker-ap-northeast-1d-x62nl"] ["ip-10-0-46-214.ap-northeast-1.compute.internal","bastion-ocp43"] ap-northeast-1aにいるworkerノードは ip-10-0-133-117.ap-northeast-1.compute.internal であることがわかりました。 次にそのノードのラベルを確認します。 $ oc get node ip-10-0-133-117.ap-northeast-1.compute.internal --show-labels NAME STATUS ROLES AGE VERSION LABELS ip-10-0-133-117.ap-northeast-1.compute.internal Ready worker 3d12h v1.16.2 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=m4.large,beta.kubernetes.io/os=linux,failure-domain.beta.kubernetes.io/region=ap-northeast-1,failure-domain.beta.kubernetes.io/zone=ap-northeast-1a,kubernetes.io/arch=amd64,kubernetes.io/hostname=ip-10-0-133-117,kubernetes.io/os=linux,node-role.kubernetes.io/worker=,node.openshift.io/os_id=rhcos ノードのセレクタとして、ラベル kubernetes.io/hostname=ip-10-0-133-117 を使うことにします。 このラベルを nodeSelector で指定し、ipvlanの追加インターフェースに対して 10.0.201.27/24 を付与するPod ipvlsan-1 のmanifestは次のようになります。 --- apiVersion: v1 kind: Pod metadata: name: ipvlan-1 labels: app: multus-ipvlan annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "network-ipvlan", "ips": [ "10.0.201.27/24" ] } ]' spec: containers: - name: centos-tools image: docker.io/centos/tools:latest command: - /sbin/init securityContext: privileged: true nodeSelector: kubernetes.io/hostname: ip-10-0-133-117 このファイルを ipvlan-ocp-27-1.yaml に保存して、下記コマンドでPodをデプロイします。 $ oc create -f ipvlan-ocp-27-1.yaml Podが起動したら、期待する設定が反映されているか確認します。 $ oc rsh ipvlan-1 ip -d addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 promiscuity 0 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: eth0@if35: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8951 qdisc noqueue state UP group default link/ether 0a:58:0a:80:02:1d brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 0 veth numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 inet 10.128.2.29/23 brd 10.128.3.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::58e8:eeff:fe0a:45bf/64 scope link valid_lft forever preferred_lft forever 4: net1@if31: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc noqueue state UNKNOWN group default link/ether 06:e5:2e:bf:58:3a brd ff:ff:ff:ff:ff:ff promiscuity 0 ipvlan mode l2 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 inet 10.0.201.27/24 brd 10.0.201.255 scope global net1 valid_lft forever preferred_lft forever inet6 fe80::6e5:2e00:1bf:583a/64 scope link valid_lft forever preferred_lft forever Multusによるipvlanの追加インターフェースが net1 として、指定したIPアドレスが付与した状態で存在することが確認できました。次にPodのルーティングテーブルを確認します。 $ oc rsh ipvlan-1 ip route show default via 10.128.2.1 dev eth0 10.0.201.0/24 dev net1 proto kernel scope link src 10.0.201.27 10.0.202.0/24 via 10.0.201.1 dev net1 10.0.203.0/24 via 10.0.201.1 dev net1 10.128.0.0/14 dev eth0 10.128.2.0/23 dev eth0 proto kernel scope link src 10.128.2.29 172.30.0.0/16 via 10.128.2.1 dev eth0 224.0.0.0/4 dev eth0 無事、NetworkAttachmentDefinitionで仕込んでおいた 10.0.202.0/24 および 10.0.203.0/24 宛てのstatic routeが設定されています。 このstatic routeにより、ipvlanの追加インターフェースを使った通信をリージョン(workerノード)をまたいで行うことができるようになります。 2つ目のPodのデプロイ 次は、ap-northeast-1cのAZにいるworkerノードにPodをデプロイします。 このAZの追加サブネットは 10.0.202.0/24 であるため、他リージョンの追加サブネットと通信するためには 宛先 nexthop 10.0.201.0/24 10.0.202.1 10.0.203.0/24 10.0.202.1 のようなstatic routeが必要になります。これを反映するように、NetworkAttachmentDefinition network-ipvlan に書いたstatic route設定の内容を次のように変更します。 spec: additionalNetworks: - name: network-ipvlan type: Raw rawCNIConfig: '{ "cniVersion": "0.3.1", "type": "ipvlan", "mode": "l2", "capabilities": {"ips": true}, "master": "ens4", "ipam": { "type": "static", "routes": [ {"dst": "10.0.201.0/24", "gw": "10.0.202.1"}, {"dst": "10.0.203.0/24", "gw": "10.0.202.1"} ] } }' 前述の oc edit networks.operator.openshift.io cluster もしくは下記の oc patch で変更を実施します。 $ oc patch networks.operator.openshift.io cluster --type merge -p '{"spec": {"additionalNetworks": [{"name": "network-ipvlan", "type": "Raw", "rawCNIConfig": "{\"cniVersion\": \"0.3.1\", \"type\": \"ipvlan\", \"mode\": \"l2\", \"capabilities\": { \"ips\": true }, \"master\": \"ens4\", \"mode\": \"l2\", \"capabilities\": { \"ips\": true }, \"ipam\": {\"type\": \"static\", \"routes\": [{ \"dst\": \"10.0.201.0/24\", \"gw\": \"10.0.202.1\" }, { \"dst\": \"10.0.203.0/24\", \"gw\": \"10.0.202.1\" }]}}"}]}}' network-ipvlan が期待する内容に変わったことが確認できたら、次のようなmanifestでPodを起動します。 --- apiVersion: v1 kind: Pod metadata: name: ipvlan-2 labels: app: multus-ipvlan annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "network-ipvlan", "ips": [ "10.0.202.27/24" ] } ]' spec: containers: - name: centos-tools image: docker.io/centos/tools:latest command: - /sbin/init securityContext: privileged: true nodeSelector: kubernetes.io/hostname: ip-10-0-158-197 nodeSelectorとしてデプロイ先のAZにいるworkerノードについたラベルを指定し、annotationでPodのIPアドレスを指定しています。 Podのデプロイができたら、Podに入ってIPアドレスを確認します。 $ oc rsh ipvlan-2 ip -d addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 promiscuity 0 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: eth0@if20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8951 qdisc noqueue state UP group default link/ether 0a:58:0a:83:00:0e brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 0 veth numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 inet 10.131.0.14/23 brd 10.131.1.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::9010:bfff:fefb:aad7/64 scope link valid_lft forever preferred_lft forever 4: net1@if17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc noqueue state UNKNOWN group default link/ether 0a:cd:aa:50:a0:b8 brd ff:ff:ff:ff:ff:ff promiscuity 0 ipvlan mode l2 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 inet 10.0.202.27/24 brd 10.0.202.255 scope global net1 valid_lft forever preferred_lft forever inet6 fe80::acd:aa00:150:a0b8/64 scope link valid_lft forever preferred_lft forever ルーティングテーブルも確認します。 $ oc rsh ipvlan-2 ip route show default via 10.131.0.1 dev eth0 10.0.201.0/24 via 10.0.202.1 dev net1 10.0.202.0/24 dev net1 proto kernel scope link src 10.0.202.27 10.0.203.0/24 via 10.0.202.1 dev net1 10.128.0.0/14 dev eth0 10.131.0.0/23 dev eth0 proto kernel scope link src 10.131.0.14 172.30.0.0/16 via 10.131.0.1 dev eth0 224.0.0.0/4 dev eth0 このAZ用のstatic route設定が無事反映されていることが確認できました。さらにPod ipvlan-1 と疎通できることも確認しておきます。 $ oc rsh ipvlan-2 ping -c 3 10.0.201.27 PING 10.0.201.27 (10.0.201.27) 56(84) bytes of data. 64 bytes from 10.0.201.27: icmp_seq=1 ttl=64 time=2.35 ms 64 bytes from 10.0.201.27: icmp_seq=2 ttl=64 time=2.34 ms 64 bytes from 10.0.201.27: icmp_seq=3 ttl=64 time=2.43 ms --- 10.0.201.27 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 2.345/2.378/2.432/0.038 ms コンテナホストでのtcpdumpの実行 実際に追加サブネットを通って通信できているかを、ホスト上でtcpdumpして確認したくなるかもしれません。コンテナホストのRHCOSはコンテナ実行に特化しているため、tcpdump等のツールは入っていないのですが、 support-tools というコンテナを使うとtcpdumpできるようになります。 まず、1つ目のPodをデプロイしたノードに入ります。 $ oc debug node/ip-10-0-133-117.ap-northeast-1.compute.internal Starting pod/ip-10-0-133-117ap-northeast-1computeinternal-debug ... To use host binaries, run `chroot /host` Pod IP: 10.0.133.117 If you don't see a command prompt, try pressing enter. sh-4.2# chroot /host sh-4.4# 次に toolbox というコマンドを実行します[ 7 ]。このコマンドを実行すると、 support-tools コンテナを取得し、privilegedかつホストネットワークを掴んだ状態でデプロイし、その中に入ります。これで、ホストのインターフェースに対してtcpdumpが使えるようになります[ 8 ]。 sh-4.4# toolbox Trying to pull registry.redhat.io/rhel8/support-tools... Getting image source signatures Copying blob 1457434f891b done Copying blob cb3c77f9bdd8 done Copying blob fd8daf2668d1 done Copying config 517597590f done Writing manifest to image destination Storing signatures 517597590ff4236b0e5e3efce75d88b2b238c19a58903f59a018fc4a40cd6cce Spawning a container 'toolbox-' with image 'registry.redhat.io/rhel8/support-tools' Detected RUN label in the container image. Using that as the default... command: podman run -it --name toolbox- --privileged --ipc=host --net=host --pid=host -e HOST=/host -e NAME=toolbox- -e IMAGE=registry.redhat.io/rhel8/support-tools:latest -v /run:/run -v /var/log:/var/log -v /etc/machine-id:/etc/machine-id -v /etc/localtime:/etc/localtime -v /:/host registry.redhat.io/rhel8/support-tools:latest [root@ip-10-0-133-117 /]# 裏で ipvlan-2 から ipvlan-1 に対してpingを打ち続けながら、この support-tools コンテナの中で ens4 に対してtcpdumpを実行してみます。 [root@ip-10-0-133-117 /]# tcpdump -enni ens4 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ens4, link-type EN10MB (Ethernet), capture size 262144 bytes 15:59:21.983883 0a:cd:aa:50:a0:b8 > 0a:65:d7:a5:30:62, ethertype IPv4 (0x0800), length 98: 10.0.202.27 > 10.0.201.27: ICMP echo request, id 16088, seq 4, length 64 15:59:21.986235 0a:65:d7:a5:30:62 > 0a:cd:aa:50:a0:b8, ethertype IPv4 (0x0800), length 98: 10.0.201.27 > 10.0.202.27: ICMP echo reply, id 16088, seq 4, length 64 15:59:22.985390 0a:cd:aa:50:a0:b8 > 0a:65:d7:a5:30:62, ethertype IPv4 (0x0800), length 98: 10.0.202.27 > 10.0.201.27: ICMP echo request, id 16088, seq 5, length 64 15:59:22.987738 0a:65:d7:a5:30:62 > 0a:cd:aa:50:a0:b8, ethertype IPv4 (0x0800), length 98: 10.0.201.27 > 10.0.202.27: ICMP echo reply, id 16088, seq 5, length 64 15:59:23.985892 0a:cd:aa:50:a0:b8 > 0a:65:d7:a5:30:62, ethertype IPv4 (0x0800), length 98: 10.0.202.27 > 10.0.201.27: ICMP echo request, id 16088, seq 6, length 64 15:59:23.988242 0a:65:d7:a5:30:62 > 0a:cd:aa:50:a0:b8, ethertype IPv4 (0x0800), length 98: 10.0.201.27 > 10.0.202.27: ICMP echo reply, id 16088, seq 6, length 64 ipvlan-1 、 ipvlan-2 のPod間で、ホストのens4を使ってICMP echo request/replyのやり取りをしていることが確認できました。 問題判別のヒント NetworkAttachmentDefinitionが期待どおり設定されない場合 NetworkAttachmentDefinitionが期待どおり設定されない場合はCNO Podのログを確認してください。 まずCNOのPod名を確認します。 $ oc -n openshift-network-operator get pod NAME READY STATUS RESTARTS AGE network-operator-5c7c7dc988-vlw6v 1/1 Running 0 25h このPodに対して、 oc logs を実行します。 $ oc -n openshift-network-operator logs -f network-operator-5c7c7dc988-vlw6v Podの起動に失敗したり、Pod manifestの設定がうまくPodに反映されない場合 Podの起動に失敗したりPod manifestの設定がうまくPodに反映されない場合は、まず oc describe pod の出力を確認してください。それで当たりがつかない場合は、デプロイ先のworkerノードのログを確認します。crioサービスのログにエラーメッセージが出ていないかを最初に見るのがよいと思います。 具体的には、workerノードにsshもしくは oc debug node でログインし、journalctlで確認します[ 9 ]。 # journalctl -u crio -f 最後に IPIインストールで構築したOpenShiftクラスタに対してサブネットとNICを追加し、Multusを使って2つのネットワークに接続するPodをデプロイし、追加サブネット経由でPod間通信ができることを確認しました。 ネットワーク構成上、PodをデプロイするAZごとに異なるstatic routeを入れる必要があり、そのためデプロイ先のAZごとにNetworkAttachmentDefinitionのCustom Resourceを作り直しました。これはとても煩雑で、できればやりたくありません。対応策はいくつか考えられます。 対応策1: コンテナホスト側でstatic routeを設定する Podにはstatic routeを書かず、コンテナホスト上でstatic routeを設定しても、同じようにパケットを流すことができます。 具体的には、コンテナホストにログインし、追加サブネット側のインターフェース ens4 に対して # ip route add to 10.0.202.0/24 via 10.0.201.1 もしくは # nmcli con mod ens4 +ipv4.routes "10.0.202.0/24 10.0.201.1" のようにstatic routeを設定します (前者は再起動すると設定が消えますが、後者は再起動してもstatic route設定が反映されます)。 対応策2: Pod のmanifestに書く 例えばstaticにIPアドレスを振るIPAMの設定をPod manifestのannotationに埋め込んだように、Podに注入するstatic routeもPod manifestに埋め込むことができれば、デプロイ先のAZが変わるたびにNetworkAttachmentDefinitionのstatic route設定を変更する必要がなくなります。また、対応策1の場合は、コンテナホストで一律にstatic routeが決まってしまいますので、Podごとにstatic routeの設定を切り替えたい場合はこちらの方法が使えるとうれしそうです。この方法の実現方法についてはupstreamで議論中で[ 10 ]、OpenShift v4.3ではまだ使えません。今後のMultusの進化に期待しましょう。 謝辞 今回も、Red HatでNFVPEをしている林さんにいろいろ教えていただきました。ありがとうございました！ つい最近出たばかりの新しいバージョンです！ ↩ 日本語版は こちら にあります。GA直後なのに日本語のドキュメントがあるなんて素敵ですね。 ↩ 日本語版は こちら ↩ RHCOS(Red Hat CoreOS) のOSイメージは、RHEL8と同じrpmパッケージを使いつつ(つまり入っているバイナリはRHEL8と同じ)、 rpm-ostree を使ってOSイメージを作成しています。rpm-ostreeは Project Atomic 由来のツールで、ユーザーデータ(/etcや/var)への影響なしにOSイメージをアトミックにロールバックできる仕組みを提供します。RHCOSは、RHELのrpmパッケージ、rpm-ostree等のProject Atomic由来のツール、CoreOS社のContainer Linuxで使っていた Ignition 等の仕組みを悪魔合体させたディストリビューションと言えます。RHCOS自体は(今のところ)、OCP(OpenShiftの製品版)のノードを動かすOSとしての使い方しかサポートされません(つまり汎用OSとして使うユースケースはサポートされません)。一方、Red Hat CoreOSのupstreamである Fedora CoreOS は、コンテナホストに特化した汎用OSとして使われることを想定して開発が進められています。 ↩ Cluster Network Operatorについては、 こちら もご参照ください。 ↩ 前の記事では、NetworkAttachmentDefinitionの内容として、 plugins 配列の中に type: ipvlan の設定と type: tuning の設定を書いていましたが、OpenShift v4.3のMultusだとこの書き方がCNOにはじかれてしまうので、少し古い書き方をしています。 ↩ toolboxはシェルスクリプトで、中で (1) podman login registry.redhat.io (2) podman pull registry.redhat.io/rhel8/support-tools (3) podman container runlabel RUN registry.redhat.io/rhel8/support-tools みたいな感じのことをやっています。 ↩ Red Hat製品で問題判別時の情報収集に使うsosreportコマンドも、 support-tools コンテナ経由で実行できるようになります。 ↩ 余談ですが、 export SYSTEMD_LESS=FRXMK を実行しておくと、journalctlコマンドのページャが横スクロールせずにターミナルの右端で折り返してくれるので、ちょっとだけ幸せになれます。 ↩ 対応策2を実現する実装として、 cni-route-override が提案されています。Pod manifestのannotationに書いたstatic routeの設定を、 cni-args から差し込みます。 ↩

Red Hatの森若です。 Red Hat Enterprise Linux 5 ELS終了および Red Hat Enterprise Linux 6の通常サポート終了について、公式にまとめたWebページを公開するよう準備しているのですが、まだしばらく時間がかかりそうです。そのため個人としてまとめた記事を書きます。 ご注意 このblog記事は読者の方に便利なようまとめていますが、森若個人による非公式なもので会社としてのものではありません。抜け漏れ間違いなどあるかもしれません。文責は全て森若個人にあります。 公式の情報が必要な場合は以下ページをご確認ください。 access.redhat.com ※2020年6月2日追記。公式のFAQが出ました。 access.redhat.com access.redhat.com 前提知識 ELP Red Hat Enterprise Linuxはサポート期間がリリース後10年間です。サポート期間を過ぎると、Extended Life Phase (ELP)と呼ばれる期間に入ります。 ELPでは、過去に出荷されたrpmパッケージの入手や、既存のナレッジに該当する問題を問いあわせることは可能なものの、ソフトウェアのメンテナンスは終了し、セキュリティ上の深刻な問題が発見されたり、お客様のシステムで回避不可能かつ深刻な問題が発生しても新規の修正は一切出荷されません。 ELS 既に廃業してしまったISVの製品を使いつづける必要があり移行先が存在しないなど、どうしてもRHELの特定メジャーバージョンを使い続けないといけない場合があります。そのようなケースのために、特定の期間、非常に制限された一部のパッケージについてだけメンテナスを維持し、root cause analysisを含めたサポートを提供するアドオン製品がExtended Life-cycle Support(ELS) です。 ELSでサポートされるパッケージは非常に限定されています。そのリストはELS提供開始の直前(または開始後)に公開されます。この記事を書いている時点で提供中の RHEL 5 ELS でメンテナンスされるパッケージのリストは以下で公開されています。 access.redhat.com ※2020年4月23日追記: RHEL 6 ELS に含まれるパッケージのリストが公開されました access.redhat.com RHELには多くのサーバソフトウェアが含まれていますが、ほとんどはELSの対象になりません。 含まれるパッケージのリストではイメージをつかみにくいかもしれませんので、以下にRHEL 5のELSに 含まれない ものの例を挙げます(ごく一部です)。 httpd, sendmail, vsftpd, bind, squid, postgresql, mysql, openssh-server, iptables, quota, net-snmp, cron, samba, dhcp, dhcpv6-client, openjdk, openldap-server RHEL ライフサイクル 2020 年 11 月 31 日 に、RHEL 5 の ELSと、RHEL 6 の メンテナンス 2が 終了します。 access.redhat.com 各バージョンについてELSの予定が異なりますので簡単にまとめます: RHEL 5 について、ELSを提供中です。2020年11月までの提供です。 RHEL 6 について、ELSの提供が予定されています。2024年6月までの提供です。 RHEL 7 について、ELSの提供予定は未公表です。提供するともしないとも決まっていません。 RHEL 8 について、ELSの提供が予定されています。期間は未定です。 どうするのがいいの? 2020年11月末までに、システムを更改することをお勧めいたします。 できればRHEL 7またはRHEL 8へ移行していただければありがたいですが、他社製品、アプライアンス、SaaSなども選択肢にはいるかと思います。2,3年以内に利用終了することが確定しているのでなければ、ライフサイクルを考えると移行先にはRHEL 8が良いです。 現在RHEL6を利用中で、どうしても移行できないもしくは移行が間にあわない場合は、緩和策としてELSを利用することが考えられます。しかし前述のとおり通常サポートの期間中と比べて非常にサポート範囲が狭くなる点と、サポート範囲が未発表である点に注意が必要です。 RHEL 7 または RHEL 8 へ移行する場合に便利な情報 以下は RHEL 7 または RHEL 8 へ移行する場合に便利な情報です。 Red Hat Insights 2019年5月から、RHEL には Red Hat Insightsが同梱されるようになりました。これはSaaS形式で提供される診断サービスで、Red Hatのナレッジをもとに作成されたルールで既知の問題を探し、レポートします。本来的には継続的に使っていくものですが、新しく構築するシステムをRed Hat Insightsで1回だけチェックするような使いかたでも、トラブルを減らすための役に立ちます。 Red Hat Insightsについては以下の記事にもうすこし具体的な紹介があります。 rheb.hatenablog.com in-place upgradeツール Red Hatの推奨は、別途新しいシステムを構築して移行することですが、ハードウェア1台だけで利用中などの場合にはむずかしいです。RHEL 6から7、7から8へシステムをアップグレードするツールを提供しています。ご利用前にバックアップを取るなどの注意をおねがいいたします。 RHEL 6.10→RHEL 7.6 へのアップグレードツール access.redhat.com RHEL 7.6→RHEL 8.1 へのアップグレードツール access.redhat.com access.redhat.com トレーニング これからはじめてRHEL 7やRHEL 8を利用しようという場合、コマンドの違いなどでとまどうことも多いかと思います。特にRHEL 6から7ではsystemdが導入されて、運用時に使うコマンドのふるまいがかわりました。 Red Hatでは公式のトレーニングを提供しており、教室またはオンラインで受講できます。オンラインで全てのコースを1年間受講できる Red Hat Learning Subscription もあります。 日本での開催予定は以下ページ下部にある「最新コーススケジュール」にて確認できます。 jp-redhat.com

この記事は、Quarkus.io のブログ記事、 Quarkus for Spring Developers の翻訳記事です。 Quarkus 1.0の登場により、LinuxコンテナネイティブおよびkubernetesネイティブのJavaマイクロサービスを開発するための革新的なプラットフォームがもたらされました。開発者は通常、新しい革新的なランタイム・フレームワークを評価する際に、既存の知識を脇に置いておく必要があります。Quarkusが他と異なるのは、Java技術に広く深く専門知識を持つエンジニア達によって作成されたことです。これにはSpring APIの互換性も含まれており、 Red Hat Runtimes にSpring Bootのサポートを提供したエンジニアによってQuarkusにもたらされました。 私はSpringの開発者です。なぜQuarkus? 一般にコンテナ化と特にKubernetes化が、クラウドネイティブアプリケーション開発のためにJavaの再評価を強いていることは、ますます明らかになってきています。Kubernetesは非常に動的な共有インフラストラクチャであり、クラスタがホストできるアプリケーションの数が増え、再配置やスケールアップ/スケールダウンなどのアプリケーションライフサイクルの変化に対する応答性が改善されると、コスト効率が向上します。従来のJavaクラウドネイティブのランタイムは、基礎となるスタック自体を再検討することなく、既存のスタックに新しい機能を重ねてきました。その結果、メモリ消費量が増えて起動時間が遅くなり、GoやNode.jsのためにJavaの深い専門知識を再教育や再ツール化し、Kubernetesクラスタへの多大な投資からより多くの価値を引き出すことに組織が諦めています。 これは非常に大きな問題で、Quarkusはまさにこの問題に取り組んでいます。Quarkusは、メモリ密度と高速起動時間に最適化されています。JVM上で動作するQuarkusアプリケーションは、他のクラウドネイティブJavaスタックと比較して、同じRAM容量で2倍近い数のアプリケーションインスタンスを提供することができ、ネイティブバイナリとしてパッケージ化した場合は、最大7倍のインスタンスを提供することができます。これは単に SubstrateVM ( GraalVM の機能)を使ってネイティブバイナリにコンパイルする以上のものです。Quarkusは従来から「非常にダイナミックな」フレームワークをKubernetesの変更不可能なインフラストラクチャに最適化しており、メモリ使用率の低減と初期化の高速化を実現しています。これらの最適化され、 十分に文書化された フレームワークは「拡張機能(extensions)」と呼ばれ、最善の組み合わせと標準APIで構成されています。その結果、 実行時の効率が大幅に向上 します。 Spring開発者はどのような既存の知識をQuarkusにもたらすことができますか? QuarkusのSpring API互換にはSpring DI、Spring Web、Spring Data JPAが含まれます。また、Spring SecurityやSpring Configのような追加のSpring APIも計画されています。JVM上で実行する場合、Quarkusアプリケーションは事実上すべてのJavaライブラリを利用できます。Javaのリフレクションを使用しない限り、多くのライブラリーはネイティブにコンパイルされます。例えば、LombokはSpring開発者に人気のあるライブラリで、ネイティブコンパイルで動作します。念のために言っておくと、QuarkusにおけるSpring APIの互換性は、既存のSpringアプリケーションを再ホストするための完全なSpringプラットフォームを意図したものではありません。その目的は、Quarkusを使って新しいアプリケーションを開発するのが自然な入門体験になるように、十分なSpring APIの互換性を提供することです。事前に最適化された拡張機能と組み合わせることで、Quarkusはマイクロサービス開発のための 驚くべき数の拡張機能 を提供します。以上のように、開発者はSpringアプリケーションをQuarkusに移行することに成功しています。 Spring Frameworkは事実上、非常に動的です。この問題に対処するため、Quarkus Spring互換拡張機能は、Spring APIを既存の拡張機能のAPIにマッピングします。既存の拡張機能は、RestEasyやCDIなど、高速な起動、メモリー使用率の削減、ネイティブコンパイルのためにすでに最適化されています。また、Quarkus Spring互換拡張機能は、Springアプリケーションコンテキストを利用しません。これらの理由から、追加のSpringライブラリーを利用しようとしてもうまくいかないでしょう。 Quarkus Spring Web 例 import java.util.List; import java.util.Optional; import org.springframework.web.bind.annotation.*; @RestController @RequestMapping( "/person" ) public class PersonController { @GetMapping(path = "/greet/{id}" , produces = "text/plain" ) public String greetPerson( @PathVariable(name = "id" ) long id) { String name= "" ; // ... return name; } @GetMapping(produces = "application/json" ) public Iterable<Person> findAll() { return personRepository.findAll(); } Quarkus Spring Repository 例 package org.acme.springmp; import java.util.List; import org.springframework.data.repository.CrudRepository; public interface PersonRepository extends CrudRepository<Person, Long> { List<Person> findByAge( int age); } Quarkus Spring Service + MicroProfile Fault Tolerance 例 import org.eclipse.microprofile.faulttolerance.Fallback; import org.eclipse.microprofile.faulttolerance.Timeout; import org.eclipse.microprofile.rest.client.inject.RestClient; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.beans.factory.annotation.Value; import org.springframework.stereotype.Service; @Service // Spring public class PersonService { @Autowired // Spring @RestClient // MicroProfile SalutationMicroProfileRestClient salutationRestClient; @Value( "${fallbackSalutation}" ) // Spring String fallbackSalutation; @CircuitBreaker(delay=5000, failureRatio=.5) // MicroProfile @Fallback(fallbackMethod = "salutationFallback" ) // MicroProfile public String getSalutation() { return salutationRestClient.getSalutation(); } Spring開発者には他にもメリットがありますか? メモリ使用率と起動時間の改善に加えて、QuarkusはSpring開発者に以下の利点を提供します。 Function as a Service(FaaS)ランタイム ネイティブバイナリにコンパイルすると、Quarkusアプリケーションは0.0015秒で起動できます。既存のSpringとJava APIの知識をFaaSの関数で使うことができます。( Azure と AWS Lambda ) ライブコーディング 「Hello World」のサンプルアプリから始めて、アプリを再起動することなく、複雑なマイクロサービスに変換します。ただ保存してブラウザを再読み込みするだけで更新を確認できます。QuarkusライブコーディングはIDEに関係なく、「うまくいく」をすぐに活用できます。 リアクティブモデルと命令モデルのサポート Quarkusには、同じアプリケーション内で従来の命令型モデル、リアクティブモデル、またはその両方をサポートするリアクティブコアがあります。 依存性注入エラーの早期検出 Quarkusは実行時ではなくコンパイル時に依存性注入エラーを確認できます。 最善のフレームワークと標準を併用 Quarkusは同じアプリケーションでSpring API互換性、Eclipse Vert.x、MicroProfile(JAX-RS、CDIなど)、リアクティブストリーム、メッセージングなどをサポートします。同じプロジェクトでSpring APIとMicroProfile APIを一緒に使うには「 @Autowire MicroProfileをSpring Bootへ 」を読んでみてください。 Spring開発者はどのようにしてQuarkusを使い始めるべきでしょうか? 推奨される手順は次のとおりです。 一般的なQuarkusの紹介として、 「 はじめに(Getting Started Guide) 」 をご覧ください。 Spring DI 、 Spring Web 、 Spring Data JPA の各ガイドをご覧ください。 code.quarkus.io を使用して新しいアプリケーションを作成してみましょう。 任意ですが、Devoxxで行ったプレゼンテーションである Kubernetes Native Spring Apps on Quarkus をご覧ください

こんにちは！（こんばんは） Red Hatで通信事業者様担当セールスの久保田です。 今日はレッドハットのオープンソース関連のセキュリティブログのご紹介です。 このブログは英語なのですが、翻訳をお手伝いしております。 Enarx コンフィデンシャルコンピューティングのコミュニティ 昨今、セキュリティ関連のニュースが巷を騒がせていますが、グローバルの通信事業者や各国の制度も対応してきています。 その中で、オープンソースの世界でも動きがあります。 コンフィデンシャルコンピューティングという言葉を聞いたことがありますか？ コンフィデンシャル コンピューティングを定義し採用の促進に取り組むコミュニティ Confidential Computing Consortium を設立したLinux Foundationの 定義 では コンフィデンシャルコンピューティングでは、暗号化されたデータをシステムの他の部分に公開することなくメモリ内で処理できるため、機密データの公開を減らし、ユーザーのコントロールと透明性を向上します。 としています。 Red Hat Enarx はそのCCCの中でオープンソースプロジェクトとして参加しています。 セキュリティブログ 本題のセキュリティブログのご紹介です。 上で述べたEnarxを始めとして、オープンソース開発やその他のセキュリティ関連の情報が Red HatのセキュリティチーフアークテクトのMike Bursellから アリス、イブとボブのブログ から発信されています。 なぜアリスとボブかというと、セキュリティ関連の通信の説明は必ずこの二人（と時々イブ）が出てくるのです。 そういうことになっているのです。 さて、このブログ、英語で発信されていますが、いくつかの記事は日本語になっています。 aliceevebob.com このブログ、毎週発信されているので、なかなか追いつかないのですが、 個人的に面白そうな記事から地道に翻訳作業を行っています。 Red Hatならではのオープンソースの活動だったり、Enarxの話だったり、一般的なITセキュリティの記事がアップされていますので ぜひのぞいてみてください。 一部ご紹介 HSM（Hardware Security Module）のお話 高価ですが（買ったことはないのですが）暗号鍵をきっちり守ってくれる仕組みです。 軍用など、セキュリティ対策を確実にしたい場合に使われるハードウェアです。 enarxのアナウンス 2019年のRed Hat Summitの際に発表されたアナウンスです。 今年の Summit でも何か進捗があれば、と期待。 ツアー もありますよ！ コンフィデンシャルコンピューティング　ー新しいHTTPSとは？ コンフィデンシャルコンピューティングについてです。 HTTPSが浸透してきたことで、セキュリティの意識が高まってきていることを感じられます。 オープンソースプロジェクトを始める7つのアドバイス Enarxを始めとする色々なオープンソースプロジェクトから、イノベーションは生まれます。 日本でもオープンソースに注目が集まってきています。 ぜひ参加してみませんか？ 2019年はenarxの年でした 2020年の発表が楽しみです！ 日本でもステッカーを配れるようなイベントがいつか開催されるでしょうか？ 皆さまの反響にかかっております。

Red Hatの森若です。今日はドキュメントを読むときの小技をご紹介します。 Red Hat製品のドキュメント Red Hat製品のドキュメントは基本的に公開されていて、特にログインなども不要で閲覧できます。(ただしナレッジベースの記事のほとんどはサブスクリプションが必要です) access.redhat.com ちょっと便利な小技として、昔からの互換性のために、 docs.redhat.com というサイトを参照すると上のページに行けます。URL直打ち派の人は便利かと思います。 ドキュメントのフォーマット Red Hatのドキュメントは、 以下の4つのフォーマットで提供されています。(古いバージョンなどで例外もあります) HTMLの複数ページ： 節ごとに分割されている複数ページのHTMLからなります。 HTMLのシングルページ： ドキュメント全体が1つのHTMLになっています。保存するならこの形式が便利かと思います。 PDF: 1つのPDFになっています。A4印刷を想定しています。 ePub: 1つのePub形式になっています。電子書籍リーダーで読めます。 僕はドキュメントを先頭からごりごり読みたい派なのですが、Red Hat製品のドキュメントのPDFを印刷すると文字が大きめなので、そんなに長くないものでも100ページくらいになって持ち運びが面倒だったりします。そのため机で作業できるときは縦長ディスプレイで「HTMLシングル」を読むことが多いです。 ePubをiOS/Android/Kindleで読む さてRHELの新しいバージョンや、今まで扱ったことがない製品を触ろうというときには大量のドキュメントを読むことになります。電車でも読もうと思うとePubで読みたくなってきます。 iOSで読む Safariで ドキュメントのWebページ を開き 製品を選び ページの一番下(サイズによっては左下)で言語を選び Available Formatsで ePub を選んでダウンロード ダウンロードしたファイルを選択するとApple Booksが起動して読めます Androidで読む 残念ながら試した範囲では Google Play booksではRed Hat製品のドキュメントが読めませんでした。 ドキュメントを登録するとなぜか以下のような表示が出て登録に失敗してしまいます。 Google Play booksでのエラー表示 そのため、 FBreader のようなローカルのePubファイルを読めるアプリケーションが別途必要です。 ブラウザで ドキュメントのWebページ を開き 製品を選び ページの一番下(サイズによっては左下)で言語を選び Available Formatsで ePub を選んでダウンロード ダウンロードしたファイルを選択するとFBreader(またはその他のアプリ)が起動して読めます Kindleで読む KindleはePubに対応していませんので、mobiに変換してやる必要があります。 PCのブラウザで ドキュメントのWebページ を開き 製品を選び ページの一番下(サイズによっては左下)で言語を選び Available Formatsで ePub を選んでダウンロード ダウンロードしたファイルを変換します。 Calibreに含まれるebook-convertコマンドで変換するには以下のようなコマンドを打ちます: $ ebook-convert ./Red_Hat_Enterprise_Linux-8-8.1_Release_Notes-ja-JP.epub .mobi Calibreのインストールが難しい場合には、以下のようなオンラインでの変換サービスもあります。 www.epubconverter.com mobiファイルをUSBでKindleへ転送するか、パーソナルドキュメントサービスへメール を送ります。 www.amazon.co.jp まとめてダウンロード 上記ではひとつずつダウンロードする方法を書きましたが、個人的には以下のような適当なスクリプトを作ってまとめてダウンロードしています。 update-docs.sh BASEURL = ' https://access.redhat.com ' RHEL8INDEX = ' https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/ ' wget -O index.html ${RHEL8INDEX} for EPUBURL in $( hreflist index.html | grep epub ) do wget --content-disposition ${BASEURL}${EPUBURL} done hreflist #! /usr/bin/perl $html = "" ; while (<>) { $html .= $_ ; } $html =~ s/ ^ ([^<]*) < / < /g ; $html =~ s/ > [^<]* < / >< /g ; $html =~ s/ < [^>]*\s href \s*\=\s*\"?( [^ \" ] +)\"?[^>]* > / $1 \n /ig ; $html =~ s/ < [^>]* > //g ; print $html ; まとめ Red Hatのドキュメントは基本的に公開されています。HTML, PDFのほかにePubもあるのでご活用ください。

Red Hatでコンサルタントをしている織です。本記事では、KubernetesのPodに複数のNICを接続するための、MultusというCNIプラグインについてご紹介します。 Multusとは MultusはKubernetesのCNI (Container Network Interface) プラグインのひとつです。典型的なKubernetesの構成では、PodにはひとつのNICしかアサインされませんが、Multusを使うとPodに追加のNICを生やして、複数のネットワークに接続することができるようになります。内部的には、Multusは複数のCNIプラグインを同時に稼働させるための「メタCNIプラグイン」として稼働します。 Multus ( https://github.com/intel/multus-cni より) Multusは、Kubernetesの Network Plumbing Working Group で議論されている Kubernetes Network Custom Resource Definition De-facto Standard という標準にしたがっており、その参照実装として開発されてきました。 準備 CentOS7とKubernetes v1.17を使って、動作検証環境を準備します。 まず、NICを2つ(eth0, eth1)持つCentOS7の仮想マシンを3台作成し、 kubeadm を使って、masterノード1台 + workerノード2台のクラスタを作成します。 Multusでは複数のCNIプラグインを併用しますが、そのうちのひとつをDefault(もしくはMaster)プラグインと呼びます。PodからAPIへの通信やLiveness/Readiness Probe等、従来のPod接続で行っていた通信は、基本的にDefaultプラグインを使います。 以下の操作では、DefaultのプラグインとしてFlannelを使います。その準備として、まず(Multusではない)普通のCNIプラグインとしてFlannelをインストールします。 kube-master $ kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml デフォルトゲートウェイが設定されているNIC(手元の環境ではeth0)でFlannelを使うように設定されます。 他方のNIC(手元の環境ではeth1)を、Podを接続するもうひとつのネットワーク接続に使用します。 次に、Multusに必要な諸々を入れます[ 1 ]。 Multusでは、接続するネットワークをNetworkAttachmentDefinition(もしくはnet-attach-def)というCustom Resourceとして表現します。下記コマンドで、その定義(CRD, Custom Resource Definition)や、MultusのCNIデーモンをデプロイするDaemonSet等をインストールします。 kube-master $ kubectl create -f https://raw.githubusercontent.com/intel/multus-cni/master/images/multus-daemonset.yml 以上で準備は完了です。インストールが完了すると、下記のような感じになります。 kube-master $ kubectl get pod --all-namespaces -o wide NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES kube-system coredns-6955765f44-bmrln 1/1 Running 0 4d2h 10.244.1.2 kube-node-2 <none> <none> kube-system coredns-6955765f44-qh567 1/1 Running 0 4d2h 10.244.0.2 kube-master <none> <none> kube-system etcd-kube-master 1/1 Running 1 4d2h 192.168.122.125 kube-master <none> <none> kube-system kube-apiserver-kube-master 1/1 Running 1 4d2h 192.168.122.125 kube-master <none> <none> kube-system kube-controller-manager-kube-master 1/1 Running 1 4d2h 192.168.122.125 kube-master <none> <none> kube-system kube-flannel-ds-amd64-fv8s4 1/1 Running 0 4d 192.168.122.172 kube-node-1 <none> <none> kube-system kube-flannel-ds-amd64-nx85b 1/1 Running 0 4d 192.168.122.143 kube-node-2 <none> <none> kube-system kube-flannel-ds-amd64-zjt4d 1/1 Running 0 4d 192.168.122.125 kube-master <none> <none> kube-system kube-multus-ds-amd64-4fhfh 1/1 Running 0 4d 192.168.122.172 kube-node-1 <none> <none> kube-system kube-multus-ds-amd64-4n2nq 1/1 Running 0 4d 192.168.122.125 kube-master <none> <none> kube-system kube-multus-ds-amd64-gkdn5 1/1 Running 0 4d 192.168.122.143 kube-node-2 <none> <none> kube-system kube-proxy-g7wwf 1/1 Running 1 4d2h 192.168.122.172 kube-node-1 <none> <none> kube-system kube-proxy-ls8x5 1/1 Running 1 4d2h 192.168.122.125 kube-master <none> <none> kube-system kube-proxy-n9w4g 1/1 Running 1 4d2h 192.168.122.143 kube-node-2 <none> <none> kube-system kube-scheduler-kube-master 1/1 Running 1 4d2h 192.168.122.125 kube-master <none> <none> この手順で作成されたCNIプラグインとしてのMultusの設定は、下記のようになります。 kube-master $ jq . /etc/cni/net.d/00-multus.conf { "cniVersion": "0.3.1", "name": "multus-cni-network", "type": "multus", "logLevel": "debug", "logFile": "/tmp/multus.log", "binDir": "/opt/multus/bin", "kubeconfig": "/etc/cni/net.d/multus.d/multus.kubeconfig", "delegates": [ { "name": "cbr0", "cniVersion": "0.3.1", "plugins": [ { "type": "flannel", "delegate": { "hairpinMode": true, "isDefaultGateway": true } }, { "type": "portmap", "capabilities": { "portMappings": true } } ] } ] } Multusインストール前のFlannelのCNI設定が、 delegates 以下にそのまま入っている形になっています。 普通のPodのデプロイ まずは従来どおり、NICをひとつだけ持つPodをデプロイします。この場合、DefaultプラグインであるFlannelのネットワークに接続します。 kube-master $ cat unmultus-pod.yaml --- apiVersion: v1 kind: Pod metadata: generateName: unmultus- labels: app: unmultus spec: containers: - name: centos-tools image: docker.io/centos/tools:latest command: - /sbin/init securityContext: privileged: true のようなmanifestを作ってデプロイします。 kube-master $ kubectl create -f unmultus-pod.yaml pod/unmultus-7wpr6 created $ kubectl get pod -l app=unmultus NAME READY STATUS RESTARTS AGE unmultus-7wpr6 1/1 Running 0 16s いつもどおり、 eth0 として veth のインターフェースがあることがわかります。 kube-master $ kubectl exec -it unmultus-7wpr6 -- ip -d addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 promiscuity 0 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: eth0@if54: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default link/ether fe:12:e9:69:80:a5 brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 0 veth numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 inet 10.244.2.47/24 brd 10.244.2.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::fc12:e9ff:fe69:80a5/64 scope link valid_lft forever preferred_lft forever vlanで追加ネットワークに接続 Multusを使って、コンテナホストのeth1にVLANサブインターフェースを作成し、それをPodの2つ目のNICとしてアサインします。 NetworkAttachmentDefinitionの定義 まず、PodをVLANで接続する追加ネットワークをNetworkAttachmentDefinitionのCustom Resourceとして定義します。ここでは vlan-conf という名前をつけています ( metadata.name: vlan-conf )。 kube-master $ cat vlan-conf.yaml --- apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: vlan-conf spec: config: '{ "cniVersion": "0.3.1", "plugins": [ { "type": "vlan", "master": "eth1", "vlanid": 100, "capabilities": { "ips": true }, "ipam": { "type": "static" } }, { "capabilities": { "mac": true }, "type": "tuning" } ] }' 今回作成したKubernetes環境は、DefaultプラグインのFlannelが作るネットワーク通信に、コンテナホストの eth0 を使っています。 上記のNetworkAttachmentDefinitionは、Podが接続する(Flannelとは別の)ネットワークとして、コンテナホスト上の eth1 が接続するVLAN ID 100のtagged VLANを使うことを意味します。 kube-master $ kubectl create -f vlan-conf.yaml networkattachmentdefinition.k8s.cni.cncf.io/vlan-conf created $ kubectl get net-attach-def vlan-conf NAME AGE vlan-conf 29s のように vlan-conf のNetworkAttachmentDefinitionオブジェクトを作成します。 Podの作成 次のようなmanifestでPodをデプロイします。 kube-master $ cat vlan-pod1.yaml --- apiVersion: v1 kind: Pod metadata: # generateName: vlan- name: vlan-172.16.1.201 labels: app: multus-vlan annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "vlan-conf", "ips": [ "172.16.1.201/24" ]} ]' spec: containers: - name: centos-tools image: docker.io/centos/tools:latest command: - /sbin/init securityContext: privileged: true metadata.annotations.k8s.v1.cni.cncf.io/networks で先ほど作成したnet-attach-defの名前 vlan-conf を指定しています。 kube-master $ kubectl create -f vlan-pod1.yaml pod/vlan-172.16.1.201 created 同様にして、うまく異なるworkerノードにスケジューリングされることを祈りつつ[ 2 ]、 172.16.1.202 のIPアドレスをアサインしたPodをデプロイします。 kube-master $ kubectl get pod -l app=multus-vlan -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES vlan-172.16.1.201 1/1 Running 0 3m44s 10.244.2.48 kube-node-1 <none> <none> vlan-172.16.1.202 1/1 Running 0 2m9s 10.244.1.24 kube-node-2 <none> <none> Pod vlan-172.16.1.201 のインターフェースを確認します。 kube-master $ kubectl exec -it vlan-172.16.1.201 -- ip -d addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 promiscuity 0 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: eth0@if61: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default link/ether b6:1e:bd:66:b9:cd brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 0 veth numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 inet 10.244.2.52/24 brd 10.244.2.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::b41e:bdff:fe66:b9cd/64 scope link valid_lft forever preferred_lft forever 4: net1@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 52:54:00:5d:8f:e5 brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 0 vlan protocol 802.1Q id 100 <REORDER_HDR> numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 inet 172.16.1.201/24 brd 172.16.1.255 scope global net1 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fe5d:8fe5/64 scope link valid_lft forever preferred_lft forever eth0 はDefaultプラグインであるFlannelにつながるインターフェースです。それに加えて、 net1 としてVLAN ID 100のvlanインターフェースが追加され、manifestで指定したIPアドレス( 172.16.2.201 )が付与されていることがわかります。 Pod vlan-172.16.1.202 の net1 も念の為確認しておきます。 kube-master $ kubectl exec -it vlan-172.16.1.202 -- ip -d addr show dev net1 4: net1@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 52:54:00:39:4d:c5 brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 0 vlan protocol 802.1Q id 100 <REORDER_HDR> numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 inet 172.16.1.202/24 brd 172.16.1.255 scope global net1 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fe39:4dc5/64 scope link valid_lft forever preferred_lft forever 同じくVLAN ID 100のvlanインターフェースとして、 172.16.1.202 がアサインされています。 このPodがスケジュールされたworkerノード kube-node-1 のインターフェースは下記のようになっています。 kube-node-1 $ ip link show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:d4:9d:eb brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:5d:8f:e5 brd ff:ff:ff:ff:ff:ff 4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN mode DEFAULT group default link/ether 8e:f7:5f:9f:84:ff brd ff:ff:ff:ff:ff:ff 5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 8a:b9:22:00:44:9b brd ff:ff:ff:ff:ff:ff 55: veth0ce3de47@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP mode DEFAULT group default link/ether fa:64:45:b0:ea:38 brd ff:ff:ff:ff:ff:ff link-netnsid 0 indexが3なのは eth1 なので、Pod内の net1 の親インターフェースはホストの eth1 であることがわかります。 また、今回は priviledged: true としてPodを起動しているので、Pod内で下記のようにして、ホスト上の物理インターフェースを確認することもできます。 kube-master $ kubectl exec -it vlan-172.16.1.201 -- cat /proc/net/vlan/net1 net1 VID: 100 REORDER_HDR: 1 dev->priv_flags: 1021 total frames received 15 total bytes received 976 Broadcast/Multicast Rcvd 15 total frames transmitted 13 total bytes transmitted 1046 Device: eth1 INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0 EGRESS priority mappings: 最後に、2つのPodの net1 同士で通信できることを確認します。 kube-master $ kubectl exec -it vlan-172.16.1.201 -- ping -c 3 172.16.1.202 PING 172.16.1.202 (172.16.1.202) 56(84) bytes of data. 64 bytes from 172.16.1.202: icmp_seq=1 ttl=64 time=0.995 ms 64 bytes from 172.16.1.202: icmp_seq=2 ttl=64 time=0.901 ms 64 bytes from 172.16.1.202: icmp_seq=3 ttl=64 time=0.667 ms --- 172.16.1.202 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 0.667/0.854/0.995/0.139 ms また、下記のようにmasterノードのeth1にVLAN ID 100のVLANサブインターフェースを作成すると、masterノードとPodの net1 の間で通信することができます。 kube-master $ sudo ip link add link eth1 name eth1.100 type vlan id 100 kube-master $ sudo ip addr add 172.16.1.10/24 dev eth1.100 kube-master $ sudo ip link set up eth1.100 kube-master $ ping -c 3 172.16.1.201 PING 172.16.1.201 (172.16.1.201) 56(84) bytes of data. 64 bytes from 172.16.1.201: icmp_seq=1 ttl=64 time=1.10 ms 64 bytes from 172.16.1.201: icmp_seq=2 ttl=64 time=0.542 ms 64 bytes from 172.16.1.201: icmp_seq=3 ttl=64 time=0.566 ms --- 172.16.1.201 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2046ms rtt min/avg/max/mdev = 0.542/0.739/1.109/0.261 ms macvlanで追加ネットワークに接続 macvlanとは macvlanは、物理インターフェースに対して、異なるMACアドレスとIPアドレスを持つ複数のサブインターフェースを作成する仕組みです。 Linuxのbridgeインターフェースと似ている部分が多いのですが、 bridgeはMAC Learning、STP等、いわゆるL2スイッチと同じ動きをする。macvlanでは、すべてのサブインターフェースのMACアドレスがわかるので、MAC LeariningやSTPは必要ない macvlanサブインターフェースと親の物理インターフェースは直接は通信できない という違いがあります。またvlanサブインターフェースとは vlanサブインターフェースは親インターフェースと同じMACアドレスを持ち、VLANタグを使って異なるL2ドメインに接続するのに対して、macvlanサブインターフェースは親インターフェースとは異なるMACアドレスを持ち、外部ネットワークに直接接続する という違いがあります。 macvlanでは、親インターフェースが複数のMACアドレス宛てのパケットを受信する必要があります。親インターフェースがUnicast filteringの機能 ( IFF_UNICAST_FLT ) をサポートする場合は、受信を許可する(macvlanサブインターフェースの)MACアドレスを明示的に登録します。Unicast filteringをサポートしない場合は親インターフェースをPromiscuousモードにします。検証で使った環境では親インターフェースとしてvirtio_netを使っており、virtio_netはUnicast filteringをサポートしています(ので、以下の例では親インターフェースはPromiscuousにはなっていません)。 いくつかの動作モードがありますが、ここでは bridge モードを使います。 NetworkAttachmentDefinitionの定義 Podをmacvlanで接続する追加ネットワークをNetworkAttachmentDefinitionのCustom Resourceとして定義します。ここでは macvlan-conf という名前をつけています ( metadata.name: macvlan-conf )。 kube-master $ cat macvlan-conf.yaml --- apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: macvlan-conf spec: config: '{ "cniVersion": "0.3.1", "plugins": [ { "type": "macvlan", "capabilities": { "ips": true }, "master": "eth1", "mode": "bridge", "ipam": { "type": "static" } }, { "capabilities": { "mac": true }, "type": "tuning" } ] }' 上記のNetworkAttachmentDefinitionでは、ホストの eth1 を親インターフェースとして、bridge modeのmacvlanインターフェースを作成し、それをPodをアサインします。 kube-master $ kubectl create -f macvlan-conf.yaml networkattachmentdefinition.k8s.cni.cncf.io/macvlan-conf created $ kubectl get net-attach-def macvlan-conf NAME AGE macvlan-conf 8s Podの作成 さらに次のようなmanifestでPodをデプロイします。 kube-master $ cat macvlan-pod1.yaml --- apiVersion: v1 kind: Pod metadata: # generateName: macvlan- name: macvlan-10.1.1.201 labels: app: multus-macvlan annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "macvlan-conf", "ips": [ "10.1.1.201/24" ] } ]' spec: containers: - name: centos-tools image: docker.io/centos/tools:latest command: - /sbin/init securityContext: privileged: true metadata.annotations.k8s.v1.cni.cncf.io/networks で、先ほど作成したnet-attach-defの名前 macvlan-conf を指定しています。 kube-master $ kubectl create -f macvlan-pod1.yaml pod/macvlan-10.1.1.201 created 同様にして、 10.1.1.202 のIPアドレスをアサインしたPodをデプロイします。 kube-master $ kubectl create -f macvlan-pod2.yaml pod/macvlan-10.1.1.202 created Podが2個デプロイされました。 kube-master $ kubectl get pod -l app=multus-macvlan -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES macvlan-10.1.1.201 1/1 Running 0 2m47s 10.244.2.49 kube-node-1 <none> <none> macvlan-10.1.1.202 1/1 Running 0 93s 10.244.1.25 kube-node-2 <none> <none> Podのインターフェースを確認すると、bridgeモードのmacvlanインターフェースとして net1 が追加され、IPアドレス 10.1.1.201 が付与されていることがわかります。 kube-master $ kubectl exec -it macvlan-10.1.1.201 -- ip -d addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 promiscuity 0 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: eth0@if56: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default link/ether 9a:6e:b6:d9:e8:a3 brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 0 veth numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 inet 10.244.2.49/24 brd 10.244.2.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::986e:b6ff:fed9:e8a3/64 scope link valid_lft forever preferred_lft forever 4: net1@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether aa:2a:7c:df:12:b9 brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 0 macvlan mode bridge numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 inet 10.1.1.201/24 brd 10.1.1.255 scope global net1 valid_lft forever preferred_lft forever inet6 fe80::a82a:7cff:fedf:12b9/64 scope link valid_lft forever preferred_lft forever デプロイしたPod間の疎通を確認します。 kube-master $ kubectl exec -it macvlan-10.1.1.201 -- ping -c 3 10.1.1.202 PING 10.1.1.202 (10.1.1.202) 56(84) bytes of data. 64 bytes from 10.1.1.202: icmp_seq=1 ttl=64 time=0.716 ms 64 bytes from 10.1.1.202: icmp_seq=2 ttl=64 time=0.858 ms 64 bytes from 10.1.1.202: icmp_seq=3 ttl=64 time=0.686 ms --- 10.1.1.202 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2008ms rtt min/avg/max/mdev = 0.686/0.753/0.858/0.078 ms デプロイしたPodとmasterノードとの疎通を確認します (masterノードのeth1に 10.1.1.1 をアサインしています)。 kube-master $ kubectl exec -it macvlan-10.1.1.201 -- ping -c 3 10.1.1.1 PING 10.1.1.1 (10.1.1.1) 56(84) bytes of data. 64 bytes from 10.1.1.1: icmp_seq=1 ttl=64 time=6.25 ms 64 bytes from 10.1.1.1: icmp_seq=2 ttl=64 time=0.638 ms 64 bytes from 10.1.1.1: icmp_seq=3 ttl=64 time=0.754 ms --- 10.1.1.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 0.638/2.548/6.252/2.619 ms ipvlanで追加ネットワークに接続 ipvlanとは ipvlanは、macvlanととてもよく似ています。macvlanとの違いは、サブインターフェースごとに固有のMACアドレスが付与されず、サブインターフェースは親インターフェースと同じMACアドレスを持つことです。ipvlanには、親インターフェースとMACアドレスを共有することに起因する、いくつかの考慮点があります。 サブインターフェースのIPアドレスをDHCPで取得するには工夫が必要。具体的には、ipvlanサブインターフェースを割り当てる仮想マシンもしくはコンテナからのリクエストに対して固有のClient IDを指定し、DHCPサーバ側ではMACアドレスではなくClient IDに対してIPアドレスを割り当てるようにする。 サブインターフェースのMACアドレスが共通であるため、MACアドレスからEUI-64フォーマットでインターフェースIDを生成するSLAACによるIPv6の自動設定は使えない 一方で、いくつかのユースケースではmacvlanよりもipvlanの方が適していると カーネルのドキュメント に記載されています。 例として挙げられているのは下記です。 親インターフェースの対向装置のポートが、ひとつのMACアドレスしか許可しないポリシーになっている 親インターフェースで処理できるMACアドレスに上限がある、Promiscuousモードにできない、(macvlanの)パフォーマンス/スケーラビリティに懸念がある サブインターフェースを割り当てるコンテナや仮想マシンが信用できない (MACアドレスを書き換えたりしてほしくない) カーネルの準備 CentOS7のカーネル(確認したバージョンは 3.10.0-957.27.2.el7 )は、ipvlanが有効になっていません。以下では、ELRepoの kernel-ml (mainline stableバージョンのupstreamカーネルをCentOS7用にコンパイルしたもの) を使ってipvlanの動作を確認しました。実際に使ったバージョンは 5.4.10-1.el7.elrepo です。 NetworkAttachmentDefinitionの定義 Podをipvlanで接続する追加ネットワークをNetworkAttachmentDefinitionのCustom Resourceとして定義します。ここでは ipvlan-conf という名前をつけています ( metadata.name: ipvlan-conf )。 kube-master $ cat ipvlan-conf.yaml --- apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: ipvlan-conf spec: config: '{ "cniVersion": "0.3.1", "plugins": [ { "type": "ipvlan", "capabilities": { "ips": true }, "master": "eth1", "ipam": { "type": "static" } }, { "capabilities": { "mac": true }, "type": "tuning" } ] }' 上記のNetworkAttachmentDefinitionでは、ホストの eth1 を親インターフェースとして、ipvlanインターフェースを作成し、それをPodをアサインします。 kube-master $ kubectl create -f ipvlan-conf.yaml networkattachmentdefinition.k8s.cni.cncf.io/ipvlan-conf created $ kubectl get net-attach-def ipvlan-conf NAME AGE ipvlan-conf 8s Podの作成 次のようなmanifestでPodをデプロイします。 kube-master $ cat ipvlan-pod1.yaml --- apiVersion: v1 kind: Pod metadata: # generateName: ipvlan- name: ipvlan-10.1.1.211 labels: app: multus-ipvlan annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "ipvlan-conf", "ips": [ "10.1.1.211/24" ] } ]' spec: containers: - name: centos-tools image: docker.io/centos/tools:latest command: - /sbin/init securityContext: privileged: true metadata.annotations.k8s.v1.cni.cncf.io/networks で、先ほど作成したnet-attach-defの名前 ipvlan-conf を指定しています。 kube-master $ kubectl create -f ipvlan-pod1.yaml pod/ipvlan-10.1.1.211 created 同様にして、 10.1.1.202 のIPアドレスをアサインしたPodをデプロイします。 kube-master $ kubectl create -f ipvlan-pod2.yaml pod/ipvlan-10.1.1.212 created Podが2個デプロイされました。 kube-master $ kubectl get pod -l app=multus-ipvlan -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES ipvlan-10.1.1.211 1/1 Running 0 73s 10.244.2.50 kube-node-1 <none> <none> ipvlan-10.1.1.212 1/1 Running 0 17s 10.244.1.26 kube-node-2 <none> <none> Podのインターフェースを確認すると、l2モードのipvlanインターフェースとして net1 が追加され、IPアドレス 10.1.1.211 が付与されていることがわかります。 kube-master $ kubectl exec -it ipvlan-10.1.1.211 -- ip -d addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 promiscuity 0 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: eth0@if57: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default link/ether 82:a6:ba:07:63:08 brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 0 veth numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 inet 10.244.2.50/24 brd 10.244.2.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::80a6:baff:fe07:6308/64 scope link valid_lft forever preferred_lft forever 4: net1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default link/ether 52:54:00:5d:8f:e5 brd ff:ff:ff:ff:ff:ff promiscuity 0 ipvlan mode l2 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 inet 10.1.1.211/24 brd 10.1.1.255 scope global net1 valid_lft forever preferred_lft forever inet6 fe80::5254:0:15d:8fe5/64 scope link valid_lft forever preferred_lft forever デプロイしたPod間の疎通を確認します。 kube-master $ kubectl exec -it ipvlan-10.1.1.211 -- ping -c 3 10.1.1.212 PING 10.1.1.212 (10.1.1.212) 56(84) bytes of data. 64 bytes from 10.1.1.212: icmp_seq=1 ttl=64 time=0.703 ms 64 bytes from 10.1.1.212: icmp_seq=2 ttl=64 time=0.781 ms 64 bytes from 10.1.1.212: icmp_seq=3 ttl=64 time=1.16 ms --- 10.1.1.212 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2078ms rtt min/avg/max/mdev = 0.703/0.881/1.161/0.202 ms デプロイしたPodとmasterノードとの疎通を確認します。 kube-master $ kubectl exec -it ipvlan-10.1.1.211 -- ping -c 3 10.1.1.1 PING 10.1.1.1 (10.1.1.1) 56(84) bytes of data. 64 bytes from 10.1.1.1: icmp_seq=1 ttl=64 time=0.708 ms 64 bytes from 10.1.1.1: icmp_seq=2 ttl=64 time=0.724 ms 64 bytes from 10.1.1.1: icmp_seq=3 ttl=64 time=0.341 ms --- 10.1.1.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2073ms rtt min/avg/max/mdev = 0.341/0.591/0.724/0.176 ms bridgeで追加ネットワークに接続 NetworkAttachmentDefinitionの定義 PodをLinux Bridge経由で接続する追加ネットワークをNetworkAttachmentDefinitionのCustom Resourceとして定義します。ここでは bridge-conf という名前をつけています ( metadata.name: bridge-conf )。 kube-master $ cat bridge-conf.yaml --- apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: bridge-conf spec: config: '{ "cniVersion": "0.3.1", "plugins": [ { "type": "bridge", "name": "br-multus", "bridge": "br-multus0", "capabilities": { "ips": true }, "ipam": { "type": "static" } } ] }' 上記のNetworkAttachmentDefinitionでは、ホストに br-multus0 という名前のブリッジを作成し、そこにPodのvethを接続します。 kube-master $ kubectl create -f bridge-conf.yaml networkattachmentdefinition.k8s.cni.cncf.io/bridge-conf created $ kubectl get net-attach-def bridge-conf NAME AGE bridge-conf 9s Podの作成 次のようなmanifestでPodをデプロイします。 kube-master $ cat bridge-pod1.yaml --- apiVersion: v1 kind: Pod metadata: # generateName: bridge- name: bridge-10.1.1.221 labels: app: multus-bridge annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "bridge-conf", "ips": [ "10.1.1.221/24" ] } ]' spec: containers: - name: centos-tools image: docker.io/centos/tools:latest command: - /sbin/init securityContext: privileged: true metadata.annotations.k8s.v1.cni.cncf.io/networks で、先ほど作成したnet-attach-defの名前 bridge-conf を指定しています。 kube-master $ kubectl create -f bridge-pod1.yaml pod/bridge-10.1.1.221 created 同様にして、 10.1.1.222 のIPアドレスをアサインしたPodをデプロイします。 kube-master $ kubectl create -f bridge-pod2.yaml pod/bridge-10.1.1.222 created Podが2個デプロイされました。 kube-master $ kubectl get pod -l app=multus-bridge -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES bridge-10.1.1.221 1/1 Running 0 97s 10.244.2.51 kube-node-1 <none> <none> bridge-10.1.1.222 1/1 Running 0 27s 10.244.1.27 kube-node-2 <none> <none> Podのインターフェースを確認すると、vethとして net1 が追加され、IPアドレス 10.1.1.221 が付与されていることがわかります。 kube-master $ kubectl exec -it bridge-10.1.1.221 -- ip -d addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 promiscuity 0 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: eth0@if63: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default link/ether f6:a7:c8:89:40:f6 brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 0 veth numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 inet 10.244.2.54/24 brd 10.244.2.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::f4a7:c8ff:fe89:40f6/64 scope link valid_lft forever preferred_lft forever 5: net1@if65: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 92:a8:48:c2:f0:55 brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 0 veth numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 inet 10.1.1.221/24 brd 10.1.1.255 scope global net1 valid_lft forever preferred_lft forever inet6 fe80::90a8:48ff:fec2:f055/64 scope link valid_lft forever preferred_lft forever Pod bridge-10.1.1.221 がスケジュールされたノード kube-node-1 上で、bridgeインターフェースを確認します。 kube-node-1 $ ip link show type bridge 5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 8a:b9:22:00:44:9b brd ff:ff:ff:ff:ff:ff 64: br-multus0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 1e:86:7b:f3:e8:da brd ff:ff:ff:ff:ff:ff Flannelで使う cni0 に加えて、net-attach-defで指定した br-multus0 というブリッジが作成されています。 kube-node-1 $ brctl show bridge name bridge id STP enabled interfaces br-multus0 8000.1e867bf3e8da no vethc1d59074 cni0 8000.8ab92200449b no veth8911ce6e vethdcfe4db8 により、ホスト上で br-multus0 に接続するインターフェースは vethc1d59074 であることがわかります。 さらにこのvethのifindexを確認します (65でした)。 kube-node-1 $ ip -d link show dev vethc1d59074 65: vethc1d59074@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-multus0 state UP mode DEFAULT group default link/ether 1e:86:7b:f3:e8:da brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 1 veth bridge_slave state forwarding priority 32 cost 2 hairpin off guard off root_block off fastleave off learning on flood on port_id 0x8001 port_no 0x1 designated_port 32769 designated_cost 0 designated_bridge 8000.1e:86:7b:f3:e8:da designated_root 8000.1e:86:7b:f3:e8:da hold_timer 0.00 message_age_timer 0.00 forward_delay_timer 0.00 topology_change_ack 0 config_pending 0 proxy_arp off proxy_arp_wifi off mcast_router 1 mcast_fast_leave off mcast_flood on addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 Pod内の net1 のインターフェース情報(下記に再掲)と突き合わせると、確かに上記 vethc1d59074 とPod bridge-10.1.1.221 の net1 がveth pairになっていることが確認できます。 kube-master $ kubectl exec -it bridge-10.1.1.221 -- ip -d link show dev net1 5: net1@if65: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default link/ether 92:a8:48:c2:f0:55 brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 0 veth addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 さて、この状態ではブリッジ br-multus0 のアップリンクが設定されていないため、異なるノード上のPodとは通信できません。 各workerノードで、 br-multus0 のアップリンクとして eth1 を設定します。 kube-node-1 $ sudo ip link set eth1 master br-multus0 kube-node-1 $ brctl show bridge name bridge id STP enabled interfaces br-multus0 8000.5254005d8fe5 no eth1 veth9b1f5832 cni0 8000.8ab92200449b no vethdcfe4db8 vethe5ca8264 こうすることで、デプロイしたPod間で疎通できるようになります。 kube-master $ kubectl exec -it bridge-10.1.1.221 -- ping -c 3 10.1.1.222 PING 10.1.1.222 (10.1.1.222) 56(84) bytes of data. 64 bytes from 10.1.1.222: icmp_seq=1 ttl=64 time=1.52 ms 64 bytes from 10.1.1.222: icmp_seq=2 ttl=64 time=0.824 ms 64 bytes from 10.1.1.222: icmp_seq=3 ttl=64 time=0.860 ms --- 10.1.1.222 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 0.824/1.070/1.527/0.324 ms デプロイしたPodとmasterノードとの疎通を確認します (masterノードのeth1に 10.1.1.1 をアサインしています)。 kube-master $ kubectl exec -it bridge-10.1.1.221 -- ping -c 3 10.1.1.1 PING 10.1.1.1 (10.1.1.1) 56(84) bytes of data. 64 bytes from 10.1.1.1: icmp_seq=1 ttl=64 time=0.601 ms 64 bytes from 10.1.1.1: icmp_seq=2 ttl=64 time=0.215 ms 64 bytes from 10.1.1.1: icmp_seq=3 ttl=64 time=0.329 ms --- 10.1.1.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2057ms rtt min/avg/max/mdev = 0.215/0.381/0.601/0.163 ms IPAM Podに割り当てるIPアドレスの管理方法もプラグイン形式になっており、現時点では3種類から選べるようになっています。 static host-local DHCP 本記事ではstaticを使用し、Podの net1 に付与するIPアドレスは、Pod manifestに直書きしました。 その他の方法については、また別途何か書く...かもしれません。 おまけ 余談ですが、レッドハットのMultus開発チームの人が使っているAnsible Playbookが ここ にあります。これを使うと、下記のような感じでKVM環境の仮想マシンとしてNICを2個持つ仮想マシンインスタンスをお手軽に構築できます。 仮想マシンを作成する [ 3 ] $ ansible-playbook -i inventory/virthost.inventory -e 'network_type=none-2nics' playbooks/virthost-setup.yml コンテナランタイムをCRI-OにしてKubernetesをインストールする [ 4 ] $ ansible-playbook -i inventory/vms.local.generated -e 'pod_network_type=none-2nics' -e 'container_runtime=crio' playbooks/kube-install.yml 謝辞 本記事を書くに当たり、Red HatでNFVPEをしている林さんにいろいろ教えていただきました。ありがとうございました！ 開発している人が身近にいるのは最高の福利厚生ですね。 もしかしたら、Multusセットアップ後にPodをデプロイすると、CNIで使うバイナリのパス関連のエラー(具体的には Failed to create pod sandbox: rpc error: code = Unknown (中略) failed to find plugin "multus" in path [/usr/libexec/cni] というメッセージ)で起動に失敗するかもしれません。その場合、 このように /opt/cni/bin を /usr/libexec/cni に変えて試してみてください。 ↩ vlanのNetworkAttachmentDefinitionを使う場合、VLAN IDごとにひとつVLANサブインターフェースを作成してPodのnetwork namespaceにアサインする、という仕組み上、ひとつのホストに同じvlan net-attach-defを使うPodを複数デプロイできないため ↩ もうすぐ ansible-playbook -i inventory/virthost.inventory -e 'network_type=2nics' playbooks/virthost-setup.yml のように変わる予定です ↩ もうすぐ ansible-playbook -i inventory/vms.local.generated -e 'network_type=2nics' -e 'container_runtime=crio' playbooks/kube-install.yml のように変わる予定です ↩

この記事は、Quarkus.io のブログ記事、 Vodafone Greece replaces Spring Boot with Quarkus の翻訳記事です。 Vodafoneギリシャはギリシャで2番目に大きな電気通信会社で、600万人以上の加入者に固定電話および携帯電話サービスを提供しています。 Vodafoneギリシャは、オンプレミスとクラウド上で多くのアプリケーションを実行しているため、クラウドリソースの消費コストは同社にとって非常に重要だ。 そのアーキテクチャの一つのコンポーネントはKubernetesベースのソフトウェアであるDigital eXperience Layer(DXL)であり、これはVodafoneのコアシステム(SOAPベースの通信)とクライアント(Web/モバイル)の間のミドルウェアとして、TMF仕様 ( https://www.tmforum.org/ )に基づいた簡単に利用できるREST APIを提供する。 その目標は、今後何年もVodafoneのデジタルサービスの中核になることだ。 そのコンポーネントはMongoDB、Kafka Streams、Redisなどの技術を活用して、旧サービスの応答性を800%以上改善すると同時に、それらをRESTフレンドリな汎用APIに変換する。DXLはSpring Bootを使って実装されていて、完全にクラウド上で動作します。また、彼らはメモリリソースの大量消費と長い起動時間を経験していたため、これらを削減する方法を探し始めました。 Vodafoneギリシャにとってもう1つの重要な懸念事項は、アプリケーションの起動時間が長いことでした。Vodafoneギリシャは起動時間を改善するために、DXLにさらに多くのクラウドリソースを割り当てることができましたが、これはクラウドコストの増加を意味していました。そこで彼らは、DXLを最適化してクラウドのリソースを消費を減らすようにする方法を見つけようと試みました。 DXLの他に、VodafoneギリシャはSpring Bootを使ってマイクロサービスの大部分を実行している。現在、彼らが開発と本番で実行しているマイクロサービスの80%はSpring Bootをベースにしているが、彼らはNode.jsによるマイクロサービスも混在しています。 彼らはどの様にQuarkusを選択したのか Spring Bootに代わるものを見つけるための彼らの選択プロセスの主な基準は、開発者の効率性、クラウドリソースの消費の低減、アプリケーションの起動時間の短縮だった。後者はユーザ体験の改善だけでなく、クラウドリソースの消費コストにも大きな影響を与えると考えた。 彼らはネイティブにコンパイル可能なフレームワークであるNode.jsとVert.xなど他の技術やフレームワークを見て評価した。彼らは、Java開発者がJavaアプリケーションを学び、Javascriptに移行するのは負担であるため、Node.jsは彼らにとって良い選択肢ではないと判断した。いくつかのフレームワークは、大きな堅実な支援者やスポンサーを求めていたため、どちらも基準を満たしていなかった。もうひとつのネイティブコンパイル可能なフレームワークは、その時点ではMongoDBドライバのコンパイルに失敗するという理由で選択されなかった。MongoDBドライバをネイティブモードで使用することはサポートされておらず、ネイティブにコンパイルできないMongoDBドライバの部分をスキップする方法もなかった。彼らが危うくVert.xを選びそうになった理由は、その優れた状況伝播能力と卓越したパフォーマンスにある。しかし、2019年の4月にQuarkusについて知り、それがVert.xをそのスタックに含め、メモリと起動時間の最適化を提供していたため、彼らはQuarkusを採用することを決めた。Vodafone ギリシャのDXL技術責任者であるChristos Sotiriou氏によると、Quarkusは「我々が必要としていた性能の向上を提供すると同時に、優れた支援者(レッドハット)を持ち、実戦でテストされた技術に依存しているように思われた」という。2019年6月、VodafoneギリシャはQuarkusで書き換えられた共通ライブラリの一部を利用したマイクロサービスのデプロイに初めて成功した。 競合する技術よりもQuarkusが選ばれたもう1つの理由は、開発者が独自の拡張を作成できることだった。さらに、コミュニティメンバーの数、プロジェクトのスターの数、Quarkus開発者によるコミュニティの問題への回答と修正への迅速な応答時間、プロジェクトのコミュニケーションチャネルを介して完全に技術的な質問に答えるRed Hat開発者の数などのプロジェクトの高い活動特性は、彼らがQuarkusを選択するための肯定的な指標でした。最後に、Red Hatへの信頼とソフトウェア市場における同社の信頼は、Red HatがスポンサーとなっているQuarkusを選択することが、同社は正しい選択をしていることを確信しました。 解決策 彼らが前進する道を決めた後、Vodafoneギリシャはまず彼らの共通内部ライブラリをSpring BootからQuarkusへ移行し始めた。共通ライブラリは、次のような分野横断的な関心ごとを網羅している。 ロギング セキュリティ DB接続 Kafka接続 分散ロギング Christos氏によると、「分散ロギングの実装はSpring Bootでは非常に困難でしたが、Quarkusではこの新しい共通ライブラリの作成は実行可能であり実現可能でした。Quarkusでマイクロサービスの受信-送信リクエストに対してヘッダ伝搬を組み立ててアクションを実行する方法は、少なくとも私たちのユースケースでは、Spring Bootよりも再利用性が高く、国を横断したチームの簡単な配置も可能になりました。」という。 現在、15のQuarkusマイクロサービスがあり、そのうちの5つは2019年9月末に本番環境へ移行した。取り組みに関しては、開発者2名がこれら最初の5つのマイクロサービスの開発に専念し、これらは現在JVMモードで稼働している。間もなく、彼らのチームは今後3ヶ月で20のマイクロサービスの提供に取り組んでいる。これまでの彼らの経験から、Spring開発者がQuarkus Javaスタックを手に入れるのは非常に簡単だったことは、Christos氏の言葉を借りれば「Spring BootからCDIベースのフレームワークへの移行には多くの労力を必要としなかった」と言うことは言及する価値がある。 QuarkusにはSpring APIの互換性があるが、Vodafoneギリシャはそれを使用する計画はない、なぜなら「マイクロサービスに2つのプログラミングモデルを混在させるのは意味がない」とChristos氏は言う。コードを清潔に保つため、Christos氏の言葉を借りればVodafoneギリシャは、「Spring構文で混乱させずにQuarkus構文のみを使用する」である。彼らの要求に対して、Quarkusスタックはすでに必要なものをすべて提供しているので、Spring Bootはまったく必要ありません。 利点 Vodafoneギリシャは、Quarkusを使用することで多くのメリットを得ています。その1つは、JVMモードではメモリリソースの消費が半分になったことだ。さらに、最適化を行わなくても、起動時間がほぼ4分の1に短縮されました。これらのマイクロサービスの多くは複雑なものだ、彼らは「多くのKafkaやデータベースと接続している」とChristos氏の説明する Kafkaを使用する同社のロギングシステムは、サイズの大きいメッセージを処理してJSONに変換するため、大量のメモリを使用する。例として、Spring Bootを使用している時にはいくつかのマイクロサービスは1GBのメモリを必要としていた。一方、本番環境で現在稼働しているQuarkusマイクロサービスは512MBで導入できるようになりました。「80個あるマイクロサービスにとって、これは大きな節約になります!」とChristos氏は強調し、「Quarkusが最適化せずにJVMモードでデフォルトで提供するものは、Springが最適化後（依存関係の管理、JVMオプションの操作など）に提供するものに比べて50～60%軽量化されている」と加えた。起動時間に関しては、その時間の大部分を占めるのはメッセージブローカやデータベースが接続の受け入れを待っている時間です。これはSpring Bootマイクロサービスが約50秒で起動させました。しかし、Quarkusマイクロサービスを使えば、そのうちの四分の一以下で起動できる(14秒)。 彼らが経験した開発者効率の大きな利点は、予想外で、嬉しい驚きだった。最初に彼らは、Spring BootからCDIベースのフレームワークへの移行には、Spring開発者の多大な労力を必要としないことに気付きました。第二に、Quarkusのライブコーディング機能(別名:devモード)を利用することで、開発者の生産性が向上した。これをChristos氏は「経験としてとても良いこと」と表現した。例えば、Christos氏によると、各開発サイクルは開発中のロジックの複雑さに応じて1~2スプリント(1スプリント=2週間)で構成される。Quarkusでは「Spring Bootに比べて開発者の生産性が30～40%向上する事が分かった。これは元Spring Boot開発者のためになる。」と語った。 彼らに感銘を与えたもうひとつの機能は、QuarkusがエンタープライズJavaを使用する方法、例えばCDIを非同期メソッドのコンテキスト伝播と組み合わせて使用する簡潔な方法などの有効性だ。マイクロサービスが他のマイクロサービスを呼び出して、他のマイクロサービスから返された情報を集約することは珍しくなく、MicroProfile Context PropagationとMicroProfile Reactive Messaging拡張を通じて、Quarkusと容易に連携することができる。実際、「MicroProfileは、開発ツールとしてQuarkusを気に入っている良い理由です。」とChristos氏は述べた。 次へ 次のステップとして、Vodafoneギリシャのマイクロサービスの数は、彼らがやろうとしていることのほんの一部しかカバーしていない。つまり、マイクロサービスの数とこの構想に専任する開発者の数を2倍にしたいのです。この目標を達成するために、同社は今後三ヶ月で20のQuarkusマイクロサービスをリリースする予定だ。Christos氏によると、成長するにつれ、「組織化と開発者の生産性は、彼らが消費するリソースにとってさらに重要になるだろう。」という。 現在はMongoDBとのインターフェース時にJVMモードでQuarkusを実行しているが、将来的にはMongoDBとネイティブコンパイルを使用することも検討している。VodafoneギリシャがQuarkusを使い始めた数ヶ月前には、MongoDB用の拡張機能は含まれていなかったが、今ではMongoDBクライアント拡張機能が含まれて利用できる。さらに、MicroProfile の耐障害性のサーキットブレーカのようなQuarkus拡張をより多く使用し、より広くMicroProfileリアクティブメッセージング仕様を採用する予定である。 さらに、JVMモードで実行しているが、Quarkusではメモリ消費と起動時間をすでに半分以上に削減している。将来的にはQuarkusマイクロサービスをネイティブモードで実行し、メモリ消費と起動時間をさらに改善する計画だ。 Quarkusについて追加の情報は Quarkus Webサイト: http://quarkus.io/ Quarkus GitHub プロジェクト: https://github.com/quarkusio/quarkus Quarkus Twitter: https://twitter.com/QuarkusIO Quarkus チャット: https://quarkusio.zulipchat.com/ Quarkus メーリングリスト: https://groups.google.com/forum/#!forum/quarkus-dev Quarkusを使う4つの理由

この記事は Red Hat Developer の Deploying debuginfod servers for your developers - Red Hat Developer を、許可をうけて翻訳したものです。debuginfodは現在活発に開発中のソフトウェアで、2020年1月時点では elfutils へのマージは完了し、Fedora 31へパッケージの提供がおこなわれていますが、まだRHELには含まれていません。   ::: Eigler December December 16, 2019::: 先の記事 では、Aaron Mereyが新しい elfutils debuginfo-server デーモンを紹介しました。このソフトウェアが elfutils 0.178 に統合され、かつ distro に含まれようとしています。あなた自身およびチームのために、なぜこのようなサービスを設定するべきか、どうやって設定するかを検討する時期になっています。 debuginfod が存在するのは、バイナリー群に関連するELF または DWARF デバッグ情報と、ソースコードを配布するためであることを思い出してください。 gdb などのデバッガー、 perf  、 systemtap などのトレーサまたはプローブツール、 binutils や pahole のようなバイナリ解析ツール、 dyninst のようなバイナリー書き換えライブラリーを実行する必要がある場合、最終的にバイナリーに一致する debuginfo  が必要です。これらのツールの debuginfod クライアントサポートにより、透過的にすぐにそれらのデータを入手することができます。プログラムを停止し、rootになり、適切な yum debuginfo-install コマンドをすべて実行してから再度試す必要がなくなります。debuginfo が利用できることで、いつでもどこでもデバッグを行えます。 ここでは、「なぜ」について説明しました。 次は、「どうやって」を見ていきましょう。 基本的なサーバー操作 クライアントがコンテンツをダウンロードできるようにするには  、それぞれで必要になる可能性がある debuginfo を提供する1台以上の debuginfod サーバーが必要になり ます。理想的には、これらの ビルドアーティファクト のコピーを保持しているマシンからできるだけ近くで debuginfod サーバーを実行するべきです。 独自のソフトウェアを構築している場合には、ビルドおよびソースツリーがどこかに存在しているはずです。ビルドマシンで debuginfod を実行するには、以下を実行します。 $ debuginfod -F /path/to/build/tree1 /path/to/build/tree2 こうすると、 debuginfod は 、これらのツリーをすべて定期的に再スキャンし、実行可能ファイルおよびデバッグデータすべてと、そこから参照されるソースファイルをすべて利用可能にします。コードをリビルドすると、インデックスはすぐに更新されます（ -t パラメーターを参照）。 独自のソフトウェアを RPM に全て構築する場合は、RPM ファイルが含まれる親 ディレクトリーで debuginfod のコピーを実行します。 $ debuginfod -R /path/to/rpm/tree1 /path/to/rpm/tree2 次に、 debuginfod は 、 これらのツリーをすべて定期的に再スキャンし、RPM内のすべての実行可能ファイルとデバッグファイルを利用可能にします。このツールは、 -debuginfo および -debugsource ファイルを自動的に対応づけします。 これらの引数を一緒に追加することで、1つの debuginfod プロセスで自然に実行できます。 Linux ディストリビューションの一部となるソフトウェアをデバッグする必要がある場合は、もうすこし話が難しくなります。ディストリビューションが公開 debuginfod サーバーを設定するようになるまでは、私達は自前でやる必要があります。幸いなことに、これはそれほど難しくありません。結局のところ必要なのは、ディストリビューションの関連パッケージがインストールされているマシン、または単にダウンロードされたマシンだけです。 $ mkdir distro-rpms ; cd distro-rpms $ debuginfod -R . 必要に応じて繰り返します。 $ yumdownloader PACKAGE-N-V-R $ yumdownloader --debuginfo PACKAGE-N-V-R ディスクに納まる限りでワイルドカードを使用します。 Red Hat Satellite サーバーを社内で実行している場合、または distro パッケージの非公式に管理されたミラーを実行している場合は、そのシステムのパッケージアーカイブ に対して debuginfod を実行できます。インストール（ rpm -i ）、フィルタリング、何かしらの方法での再構成は不要です。 debuginfod のコピーにディレクトリーをスキャンさせるだけです。 クライアント設定 これで1つまたは複数のサーバーを実行していて、 debuginfo の同じツリーまたは異なるツリーをスキャンできる状態になりました。クライアントと通信させる方法は?シンプルで明白な解決法は、知っているすべてのサーバーを列挙することです。 $ export DEBUGINFOD_URLS=" http://host1:8002/ http://host2:8002/ ...." $ gdb ... etc. ルックアップのたびに、クライアントはすべてのサーバーにクエリを一度に送信し、要求された情報を報告する最初のサーバーが「勝ちます」。 この戦術は機能しますが、いくつかの欠点があります。まず、このURLのリストをすべてのクライアントに伝達する必要があります。第二に、コンテンツを集中的にキャッシュする機会がないため、各クライアントは（HTTPの用語で）オリジンサーバーからコンテンツを個別にダウンロードする必要があります。この問題には単純な対策があります：フェデレーションです。 各 debuginfod サーバーはクライアントとしても機能します。サーバーがローカルインデックスではクエリーに応答できず、アップストリームの $DEBUGINFO_URLS のリストが設定されている場合は、要求はアップストリームサーバーに転送されます。その後、正しい応答の結果をキャッシュして、リレーします。同じオブジェクトへの次の要求は、キャッシュ（キャッシュ保持制約の対象）から提供されます。 この動作により、 debuginfod サーバーのフェデレーション階層を設定できます。 そうすることで、設定ファイルの集中化とキャッシュの局所化が可能になります。次に、ビルドシステムごとの debuginfod のそれぞれは、その上位ピアのリストで構成できます。ローカルディレクトリーをまったくスキャンしない よう にして、純粋にアップストリームのリレーとして機能するように debuginfod サーバーを実行することも可能になります。フェデレーションがツリーであるか、または有向非巡回グラフであることを確認します。サイクルはまずいです。 サーバー管理 これで1台以上のサーバーが実行され、それらに依存するクライアントができました。それらをうまく実行させ続けるにはどうしたらいいですか？現実的な問題がいくつかあります。 これは、インデックス中およびインデックス後におけるリソースの使用です。最初の debuginfod インデックス作成 はCPU およびストレージに集中しています。現在は、すべての ELF または DWARF ファイルを解析する必要があります。インデックスデータベースは密にフォーマットされた SQLite ファイルですが、通常の圧縮 RPM のサイズの約 1％まで拡大する可能性があります。この側面が問題でない場合は、この次の段落について心配する必要はありません。 アーカイブのセットが非常に大きい場合にインデックスの時間とスペースが過大な場合は、ファイルフィルターつきで debuginfod を実行すると便利です。 -I オプションおよび -X オプションを使用すると、ファイル名に正規表現を指定して、含めるか除外を指定できます。たとえば、アーカイブには複数の異なる様々なアーキテクチャーが混在している、またはファイルの異なる主要な distro バージョンがあり、サブセットのみを追跡したいとします。これらのオプションを使用すると、 debuginfod が 、名前がパターンに一致しないファイルをスキップできます。 $ debuginfod -I '\.el[78]\.x86_64' -X 'python' -R /path サーバーに多数のコアがある場合、 debuginfod はコマンドラインで指定されたパスごとに1つまたは2つのスレッドを開始するため、スキャンパスを多数のサブパスに分割することを検討してください。実際の同時実行数は慎重に管理されるため、パスリストの数を多く指定する際に心配はいりません。したがって、 次のようにする代わりに $ debuginfod -R /path 以下のようにします。 $ debuginfod -R /path/* ELF、DWARF、またはRPMアーカイブが非常に大きい場合は、各ストレージサーバーの近くで実行される debuginfod の複数のコピー間でスキャンタスクを分割することを検討できます。ワイルドカードに加えて包含パスと除外パスを使用して、各 debuginfod プロセスにデータのサブセットのみを与えることができます。 debuginfod サーバーがどのように連携できるかについては、上記で説明しました。この機能を使用して、何もスキャンせず、安定したシャード全体にクエリを委任する単一のフロントエンド debuginfod を作成します。 手作業でネットワークサーバーをシェルで実行することは、昔ながらの方法で遊ぶのには適しています。ただし、深刻な展開の場合は、 debuginfod サーバーをスーパーバイザシステムで管理する必要があります。 debuginfod はプレーンシェルで非常にうまく動作するため、 systemd サービスまたはコンテナ内で動作します。elfutilsにはサンプルの systemd 設定が含まれていて、さらに Red Hat OpenShift 内で debuginfod を実行したり、別のオーケストレーションサービス上で実行したりすることができるように dockerfile またはコンテナーイメージを公開する計画があります。 サーバーが実行されたら、それを監視して実行し続けることをお勧めします。テキストログは標準出力とエラーストリームに送られ、 systemd ジャーナルやOpenShiftなどのツールが出力を収集できます。さらに詳細なトレースを生成するには、 -v 冗長オプションを追加します。このテキストデータに加えて、 debuginfod は /metrics Web API URLを提供します。これは、Prometheusエクスポート形式の定量的データソースです。この URL は、サーバースレッドの現在の状態かについての内部統計を提供します。 さまざまな種類の異常を検出するためにアラートシステムまたは他のプログラムを接続するのは難しくありません。 debuginfod サービスがインターネットや公衆などの信頼境界を越えて提供されるとすぐに、セキュリティが問題になります。「man」ページには、このようなサービスがユーザーとサービスオペレーターの両方にとって安全であるために必要な対策について、非常に多くの注意が示されています。非常に難しいわけではありませんが、HAProxyを使用するなどの、TLS暗号化や負荷制御などの通常のHTTPフロントエンド保護は必須です。また、debuginfodのインデックス作成を信頼できる（敵意のない）バイナリに制限することも重要です。 今後の展望 将来はどうなりますか？Debianフォーマットパッケージをすぐにサポートし、そのエコシステムの人々も最大限に活用できるようにしたいです。Linuxディストリビューションがユーザー向けの公開 debuginfod サービスを運用するのを喜んで支援し、すでにこのサービスを Fedora koji でプロトタイプ化しています。また、より管理しやすくする機能や、おそらくソースバージョン管理システムとの統合も想定しています。 アーリーアダプター(あなたです!)からの提案も歓迎します。 この記事が、あなたのモチベーションを高め、独自の debuginfod サービスをセットアップするのに役立つことを願っています。 elfutils-devel@sourceware.org メーリングリストでご連絡ください。

原文はこちら https://quarkus.io/blog/quarkus-newsletter-3/ Quarkus ニュースレターの第三弾は、去りゆく2019年の最後の数週間のためのいくつかの読み物を紹介します。 今回はQuarkusに関する最初の本を手に入れました! どこか物足りないと思ったときや、今後のQuarkus Newsletterに記事が出てくるときに見逃さないようにするには、ノートパソコンと携帯電話にブックマークレットをインストールして、簡単に記事を提示できるようにしましょう。 手動の方法を希望する場合は、簡単な説明とURLで関心事を開いてください。 楽しんで! 記事とBlog Baeldung氏がLiquibaseを例にQuarkus拡張の実装方法を紹介する。 Quarkus拡張の実装方法 　投稿場所 Baeldung.com、投稿者 Baeldung氏、投稿日 2019年12月2日 Max氏はQuarkusがJavaの世界でどのように稀少であり、それが彼と彼の仕事にどのような影響を与えたかについての彼の見解を述べている。 Javaの希少性 　投稿場所　Red Hat（個人）、投稿者　Max Rydahl Andersen氏、投稿日　2019年12月1日 書籍 FrancescoはQuarkusに関する書籍を出版した最初の企業であり、その書籍ではQuarkusをクラウドのネイティブアプリケーションに利用する方法を解説している。 JavaとQuarkusを使ったクラウドネイティブアプリケーションのハンズオン:Kubernetes上でハイパフォーマンスなJavaマイクロサービスを構築 　投稿場所　Packt / Red Hat、投稿者　Francesco Marchioni氏、投稿日　2019年12月13日 ポッドキャスト Claus氏とLuca氏がCamel 3の新機能について議論し、Quarkusのサポートに触れた。 JBoss コミュニティ Asylum: ポッドキャスト#47 - 3つのこぶがあるCamelを何と呼びますか? 　投稿場所　JBoss Asylum / Red Hat、投稿者　Claus Ibsen氏、Luca Burgazolli氏、Emmanuel Bernard氏、Max Rydahl Andersen氏、投稿日　2019年12月16日 Quarkus 1.0リリース、SpringBootからQuarkusへの移行の動機、Spring API互換性レイヤ - Dimitris Andreadis氏との会話 Airhacks #64 - Quarkus 1.0とSpringBoot 　投稿場所　Red Hat / Adam Bien、投稿者　Dimitris Andreadis/Adam Bien氏、投稿日　2019年12月4日 ビデオ Thomas氏はQuarkus、GraalVM、そしてDockerが高速で軽量なマイクロサービスの開発と運用に最適なプラットフォームであることを示している。 Quarkusはクラウド向けの最速のJavaマイクロサービスランタイム？ (ドイツ語)　投稿場所　predic8、投稿者　predic8氏、投稿日　2019年11月21日

原文はこちら Quarkus 1.1.1.Final released - Bugfixes only 私たちは先頃1.1 .1.Finalをリリースし、一連のバグ修正とドキュメントの改善を早めに行ったところです。私たちは、次の大きなバージョンであろう1.2のリリースに向けて、まだ懸命に準備をしています。 これは、1.1 .0を使っているすべての人にとって安全なアップグレードです。 何が新しいの？ バグの修正とドキュメントの改善 1.1ではGradleサポートに大きな変更を加え、興味深いフィードバックを得ることができました。1.1 .1.Finalでは、これまでに報告されたすべての問題が修正されています。 また、Kotlinサポートでいくつかの点を改善しました。 それとは別に、私たちはあちこちで小さな問題を修正し、ドキュメントを改善しました。 全ての変更記録 1.1.1.Finalの完全な変更ログはGitHubで 入手できます。 貢献者 Quarkusには現在 208人の貢献者 がいます。皆様、本当にありがとうございました。 特に1.1.1リリースについてはみなさんのおかげです。 Akito Kidani, Alex Soto, Andreas Paschwitz, Andy Damevin, Arne Mejlholm, Bruno Devaux, George Gastaldi, Georgios Andrianakis, Grzegorz Piwowarek, Guillaume Smet, Gunnar Morling, Ian Wormsbecker, Jaikiran Pai, Loïc Mathieu, Manyanda Chitimbo, Mark Little, Matej Novotny, Max Rydahl Andersen, Michael J. Simons, Romain Quinio and Vinícius Ferraz Campos Florentino. 参加しよう 私たちはあなたのフィードバックをとても大切にしていますので、バグを報告し、改善を依頼してください...一緒に何か素晴らしいものを作りましょう! Quarkusのユーザーや好奇心の強い人は、恥ずかしがらずに歓迎コミュニティに参加してください。 GitHub にフィードバックを提供する; コードを作成して PRを行う ; Zulip や メーリングリスト で議論する; なにか質問があれば Stack Overflow で投稿してください。

この記事は Red Hat Developer の Introducing debuginfod , the elfutils debuginfo server を、許可をうけて翻訳したものです。debuginfodは現在活発に開発中のソフトウェアで、2020年1月時点では elfutils へのマージが完了し、Fedora 31には含まれましたがまだRHELには含まれていません。      :::By Aaron Merey October 14, 2019 ::: バグを避けることはできないので、開発者は Systemtap や GDB などのデバッグツールへ素早くかつ簡単にアクセスできる必要があります。これらのツールは典型的には DWARF (Debugging With Attributed Record Formats)を含むdebuginfoやソースファイルに依存します。これらのリソースへのアクセスは、独自のローカルビルドツリーをデバッグする場合には問題とはなりませんが、ほとんどの場合すぐには利用できません。 たとえば、ディストリビューションではデバッグする実行可能ファイルとは別に debuginfo およびソースファイルをパッケージ 化していて、あなたにはこれらのパッケージをインストールする権限がないケースが考えられます。または、これらのリソースを含んで構築されていないコンテナー内でデバッグする場合や、マシン上でこれらのファイルを置くために領域を使いたくない場合があります。 Debuginfo ファイルは、大量の領域を占め、対応する実行可能ファイルの5倍から15倍といったサイズになることもあります。 debuginfod は、この問題を解決する ことを目指しています。 debuginfod とは何ですか？どのように動作しますか？ debuginfod は、デバッガーのようなツールに対してデバッグリソースを提供する HTTP ファイルサーバーです。このサーバーはディレクトリーツリーと RPM アーカイブを定期的にスキャンし、実行可能ファイルや debuginfo ファイルのビルド ID を展開します。これには、ビルド ID をファイル名または（パッケージ、コンテンツ）のタプルに対応づける SQLite データベースが含まれます。 ビルド ID は、ELF ノートとしてオブジェクトファイルに埋め込まれた一意なハッシュ値です。 $ eu-readelf -n foo | grep Build.ID Build ID: be1743a97c6afb4a066a93c57499e9fba41cbcd5 この ID は、この10 年間にわたりGCCでデフォルトで有効化されており、LLVMでもサポートされています。詳細は Fedora wiki を参照してください。 また debuginfod は、特定のビルド ID に関連するソースファイルも提供します。ソースファイルにはビルド ID が含まれないため、 debuginfod は、ソースファイルの場所を決定するために、対応する debuginfo または実行ファイルに含まれるビルド ID およびソースパス情報に依存します。 debuginfod はどのように使用しますか？ 以下に例を示します。 $ debuginfod -vv -R /var/tmp/rpmbuild -F /usr/lib/debug [...] Opened database /home/amerey/.debuginfod.sqlite [...] Searching for ELF/DWARF files under /usr/lib/debug [...] Searching for RPMs under /var/tmp/rpmbuild [...] fts/rpm traversed /var/tmp/rpmbuild [...] debuginfo=386, executable=0, sourcerefs=34119, sourcedefs=3398 [...] fts traversed /usr/lib/debug [...] debuginfo=8071, executables=2, source=1958339 [...] Started http server on IPv4 IPv6 port=8002 サーバーへの問いあわせには、 debuginfod パッケージに含まれる debuginfod-find コマンドラインツールを使用できます。 debuginfod-find  コマンドは、特定の debuginfo、実行可能ファイル、またはソースファイルについて $DEBUGINFOD_URLS 環境変数に含まれる URL へ問いあわせます。ファイルが正常に取得されると、このコマンドはローカルキャッシュに保存し、ファイルのパスを出力します。 $ export DEBUGINFOD_URLS=" http://buildhost:8002/ " $ debuginfod-find source BUILD-ID /path/to/foo.c /home/amerey/.debuginfod_client_cache/source#path#to#foo#c $ debuginfod-find debuginfo BUILD-ID /home/amerey/.debuginfod_client_cache/debuginfo debuginfod には共有ライブラリー libdebuginfod も含まれます。このライブラリーを使用すると、ツールは debuginfod サーバーにビルド ID（ソースファイルの取得を試みる場合はパスも）を使用して、debuginfo、実行可能ファイル、またはソースファイルの問いあわせを行えます。 debuginfod-find と同様、このファイルはサーバーからローカルキャッシュにダウンロードされ、特別なパーミッションなしにツールで利用できるようになります。 debuginfod クライアントサポートをツール に 追加する方法として、ツールがファイルを見つけることができない場合に、サーバーにクエリーするフォールバックコードを追加する方法があります。この実装により、ツールの通常の動作を変更しなくても debuginfod 機能を追加できます（当然ながら、 libdebuginfod は 開発者が妥当だと考える任意の方法で統合できます）。 elfutils および GDB 用のプロトタイプ debuginfod クライアント があります（「 debuginfod を取得する方法」を参照）。以下のコードは、GDB の debuginfo 検索ルーチンに debuginfod 機能 を追加するパッチに基づいています。このプロトタイプで、 debuginfod クライアント機能で必要なコードは小さく済むことがわかります。 #if HAVE_LIBDEBUGINFOD if ([separate debuginfo should exist but was not found]) { const struct bfd_build_id *build_id; char *debugfile_path; build_id = build_id_bfd_get (objfile->obfd); int fd = debuginfod_find_debuginfo (build_id->data, build_id->size, &debugfile_path); if (fd >= 0) { /* debuginfo successfully retrieved from server. */ gdb_bfd_ref_ptr debug_bfd (symfile_bfd_open (debugfile_path)); symbol_file_add_separate (debug_bfd.get (), debugfile_path, symfile_flags, objfile); close (fd); free (debugfile_path); } } #endif /* LIBDEBUGINFOD */ ターゲットの debuginfo ファイルのビルド ID を debuginfod_find_debuginfo() に渡します。この関数は、 debuginfod サーバー にファイルを問いあわせし、正常に取得できれば、ファイルのローカルコピーのファイル記述子とパスが GDB から利用できるので Binary File Descriptor (BFD) ライブラリーを使用してファイルを開き、デバッグ対象の対応するオブジェクトファイルと関連付けます。 また、Systemtap などの elfutils ベースのツールは、elfutils debuginfod クライアント から debuginfod 機能 を自動的に継承します。 stap コマンドと  gdb コマンドを実行可能ファイル foo で実行しようとして、debuginfo やソースコードをローカルに持っていない場合を考えます。glibc debuginfo もソースファイルもありません。 $ stap -e 'probe process("/path/to/foo").function("*") { [...] }' semantic error: while resolving probe point: identifier 'process' at t.stp:1:7 source: probe process("/path/to/foo").function("*") { semantic error: no match $ gdb /path/to/foo [...] Reading symbols from /path/to/foo... (No debugging symbols found in /path/to/foo) foo のビルドツリーと glibc debuginfo RPM を使ってリモートマシン上で debuginfod サーバーを起動し、ローカルマシンの stap インスタンスおよび gdb インスタンスが利用できるようにします。 $ debuginfod -p PORT -F foo_build/ -R debug_rpms/ [...] [...] Started http server on IPv6 IPv6 port=PORT $ export DEBUGINFOD_URLS=" http://foobuildhost:PORT/ " $ stap -v -e probe process("/path/to/foo").function("*") { [...] }' [...] Pass 5: starting run ^C $ gdb /path/to/foo [...] Reading symbols from /home/amerey/.debuginfod_client_cache/debuginfo... (gdb) break printf [...] (gdb) run [...] Breakpoint 1, __printf (format=0x40201e, "main\n") at printf.c:28 28 { (gdb) list [...] 26 int 27 __printf (const char *format, ...) 28 { 29 va_list arg; 30 int done; [...] これで、 debuginfod サーバー から必要なファイルを取得できるようになりました。 stap で foo を正常にプローブできます（「 Pass 5: starting run」でわかります）。 gdb では、C ライブラリー関数への呼び出しに加えて、 foo のソースコードをデバッグして表示できます。サーバーがターゲットファイルを見つけることができない場合には、 debuginfod は 要求を他の debuginfod サーバー へ委譲するよう簡単に設定できます。 $DEBUGINFOD_URL 環境変数に他の debuginfod サーバーの URL を追加するだけです。 debuginfod を入手する方法 現時点では、 debuginfod サーバー 、 コマンドラインインターフェース、共有ライブラリーのプロトタイプ、それらのドキュメントは elfutils Git リポジトリー から利用できます。 debuginfod は 、今後の elfutilsリリースに組み込むことが計画されています(訳注: elfutils 0.178でマージされました)。プロトタイプGDB クライアントは、GDB Git リポジトリーの 実験的ブランチ で利用できます。また、 debuginfod バイナリーは Fedora COPR でも利用でき、コマンドラインから以下のようにダウンロードできます。 yum copr enable fche/elfutils yum -y install elfutils-debuginfod debuginfod の今後 binutils や LLDB などの他 の ツールに debuginfod クライアント機能を追加する作業を行っています。また、 Debian パッケージフォーマット のサポートを行うこと、Fedora の Koji ビルドシステム で debuginfod サーバーを実行すること、そしてDWARF コンテンツクエリーをサポートするよう debuginfod の web API を拡張することも計画しています。 支援またはフィードバックは常に歓迎されます。elfutils-devel@sourceware.org または irc.freenode.net の #elfutils チャンネルに連絡してください。   ※訳者注:  続きの記事を翻訳しました。以下でごらんいただけます。 rheb.hatenablog.com  

原文はこちら Quarkus 1.1.0.Final released - Template engine, YAML configuration, and more Quarkus 1.1 .0.Finalが年末年始に間に合うように登場し、すべての拡張機能(Camel Quarkusを含む)の準備ができました。 このバージョンの開始時には、いくつかの紆余曲折がありましたが、それは良い話です。Quteテンプレートエンジン、YAML設定のサポート、Gradleの改善、新しいロギング拡張、Quartz拡張などの新機能が満載です。 このブログ記事 で説明しているように、GraalVM 19.3のアップグレードは1.1 .0.Finalで元に戻しました。ネイティブ実行ファイルを構築するためにサポートしているGraalVMのバージョンは19.2 .1です。 私たちはGraalVMチームと協力して,19.3へのアップグレードを妨げる問題の修正に積極的に取り組んでいます。 何が新しいの？ Quteテンプレートエンジン これは私たちがQuarkusの最初から考えていたことで、私たちのアプローチに合わせて調整されたテンプレートエンジンを提供し、ビルド時にできることはすべて行う、というものです。 1.1には、私たちのビルドタイムテンプレートエンジンであるQuteの最初のバージョンが入っています。現在は試験的とマークされていますので、ぜひ試してみて、 メーリングリスト や イシュートラッカー でフィードバックを送ってください! 我々は、 導入ガイド と より包括的なリファレンスガイド を用意しました。 構成フレームワークの変更 更新された構成フレームワークは、特に環境変数を扱う場合に、多くの長年の構成問題を修正します。 1.1にはQuarkus設定用のYAMLサポートも含まれている:config-yaml拡張機能を追加すると、Quarkusはapplication.yamlファイルを読込まないでしょう。詳細については、 コンフィギュレーションガイド を参照してください。 Spring Security APIのためのQuarkus拡張機能 私たちはSpring APIのサポートに向けた開発を続けており、1.1ではSpring Security APIを追加しています。詳細は、 Spring Security API の拡張機能ガイド を参照してください。 Gradle の変更 GradleでQuarkusを使用しているなら、大きな変更に備えてください:Gradle6にアップグレードしたので、Gradleプラグインの宣言方法を変更する必要があります。 詳細については、 移行ガイド を参照してください。 また、デフォルトでネイティブ実行可能ファイルのビルドをトリガーしなくなりました。あなたは明確に/gradlew buildNativeとしてネイティブ実行可能ファイルを構築する必要があります。 ロギングの改善 1.1では、ロギングレイヤにいくつかの大きな改良が加えられています。 logging-gelf拡張機能を介してGraylog Extended Log Format(GELF)がサポートされるようになりました。ログをELKまたはEFKスタックにプッシュできます。この新しい可能性については、 ログの集中管理ガイド を参照してください。 ログをJSONとしてフォーマットできるように、logging-json拡張機能を追加しました。詳細は ロギングのドキュメント を確認してください。 アプリケーション例外のモニターを可能にするlogging-sentry拡張機能が追加されました。 私たちのドキュメントで述べたように 、Sentryはもはやオープンソースではないことに注意してください。 ヘルスチェック Quarkusの監視は継続的に改善されており、重要な要素の1つはデフォルトのヘルスチェックとメトリックを持つことです。Quarkusの将来のバージョンでは、理にかなうすべての拡張機能にこれらが統合される予定です。 1.1では、既存のAgroalデータソースチェックに加えて、Kafka、Kafka Streams、MongoDB、Neo4j、Artemisのヘルスチェックが追加されました Kogito 0.6 Kogitoは0.6にアップグレードされました。専用サービス(ジョブサービス)に外部化できる活動を基準とした時間を処理する機能を備えています。QuarkusとリアクティブなノンブロッキングAPIをフルに活用して,スケジュールされたジョブ(Vert.xタイマーを使用)を効果的に処理します。さらに、データ・インデックス・サービスのGraphQLインターフェースが拡張され、ドメイン情報に対する型付き検索が可能になり、Kogitoランタイム・サービス(プロセス)によって生成されたデータを最大限の柔軟性で処理できるようになりました。 ジョブとデータインデックスサービスの詳細については、 Kogito wiki を参照してください。 Quartz 拡張機能 初期の頃から、Quarkusにはスケジューラ拡張機能がありましたが、基盤となるQuartzの仕様が公開されなかったため、クラスタ化されたジョブをサポートできませんでした。 一般的な要件であったため、1.1にはquartz拡張機能が追加され、クラスタ化されたジョブをサポートするようになりました。また ガイドとクイックスタート が追加されました。 ADOPTERS.md Quarkusの使用に関する情報を共有するために、リポジトリのルートに ADOPTERS.mdファイル を追加しました。 Quarkusを使っていて、ブログでのインタビューや、このファイルへの追加をご希望の場合は、ご連絡いただければ幸いです。 さらに Keycloak 8がサポートされるようになりました。 Hibernate ORM with PanacheとMongoDB with PanacheがOptionalをサポートします。またHibernate ORM with Panacheがロックをサポートします。 Hibernate Search+Elasticsearch(プレビュー):Beta3にアップグレードしました。互換性のない変更がいくつかありますので、 移行ガイド をご覧ください。 Neo4j(プレビュー):4.0の最終バージョンへのアップグレードには、 いくつかの重要な変更 が加えられています。 Kubernetes拡張機能を使用してKnativeマニフェストを生成できるようになりました。 QuarkusのAmazonのLambdaアーキタイプはSAMテンプレートを提供します。 quarkus.flyway.clean-at-start構成がFlyway拡張機能に追加されました。 全ての変更記録 1.1 .0.CR1 と 1.1 .0.Final の完全な変更ログはGitHubで入手できます。 Contributors Quarkusには現在206人のコントリビュータがいます。私たちは200人を超えており、あなたの貢献を楽しみにしています。一人一人に感謝します。 特に1.1 .0リリースでは以下の方々のおかげです。 Alessio Soldano, Alex Kochnev, Alex Soto, Alexander Zimmermann, Alexey Loubyansky, Anamarija Talijanac, Andrew Guibert, Andy Damevin, Aurea Munoz, Claus Ibsen, Clement Escoffier, Cristiano Nicolai, CSTDev, Danilo Magalhães, David M. Lloyd, David Walluck, Dennis Baerten, Elegie, Emmanuel Bernard, Eric Wittmann, Erik Jan de Wit, Erin Schnabel, Fabian Martinez, Fabio Heer, Filippe Spolti, Galder Zamarreño, George Gastaldi, Georgios Andrianakis, Guillaume Smet, Gunnar Morling, Gwenneg Lepage, Gytis Trikleris, Hantsy Bai, Hebert Coelho, Ioannis Canellos, Irena Kezic, Jacob Middag, Jaikiran Pai, Jan Martiska, Johannes, John O’Hara, John Oliver, Jonas Eriksson, Jonas Scholz, Jorge Solórzano, Jose Quaresma, Justin Holmes, Justin Lee, Ken Finnigan, Kevin Viet, Logan Hauspie, Loïc Mathieu, Luca Masini, Maciej Swiderski, Manyanda Chitimbo, Marcin Czeczko, Martin Kouba, Martin Stefanko, Matej Novotny, Max Rydahl Andersen, Michael Musgrove, Michael Simons, Michal Karm Babacek, Michał Szynkiewicz, Moncef Aoudia, Ondra Chaloupka, Paul Robinson, Pedro Igor, Rohan Maity, Rostislav Svoboda, Sanne Grinovero, Sebastien Blanc, Sergey Beryozkin, Simon Bengtsson, soberich, Stuart Douglas, Stéphane Épardaud, Tako Schotanus, Tiago Dolphine, Timothy Power, Vincent Sevel, Vinicius Ferraz, William Burns and Yoann Rodière. Come Join Us 私たちはあなたのフィードバックをとても大切にしていますので、バグを報告して、改善を求めてください...。一緒に何かを作ろう! Quarkusユーザや興味のある方は、遠慮せずに歓迎コミュニティに参加してください。 GitHub にフィードバックを提供する; コードを作成して PRを行う ; Zulip や メーリングリスト で議論する; なにか質問があれば Stack Overflow で投稿してください。