はてなブックマーク

アルゴCDは、アプリケーションがデプロイ先で、目的の状態となるようにデプロイを自動化する。 デプロイするアプリケーションの更新を追跡、Gitコミット時のタグによる特定バージョンのデプロイなども可能である。 アルゴCDは、Kubernetesコントローラとして実装され、アプリケーションの動作を継続的にモニターして、現在状態から目的とする状態へ変えていく、ウェブ画面からの変更ではできず、Gitリポジトリを通じて状態を設定する。 デプロイされたアプリケーションの現状が、目的とする状態から外れることを OutOfSync (同期外） とみなす。 アルゴCDは、目的とする状態と現状の差異を視覚化しレポートする。現状を目的の状態にするために、自動的同期または手動同期の手段を提供する。 自動的同期では、Gitリポジトリでターゲット状態へ加えられた変更は自動的に適用され、指定された環境へ反映される。 次は

Argo workflow の言葉のイメージから、人と人が連携して仕事を熟すためのツールと間違えそうだが、そうではなく、コンテナ化されたバッチアプリケーションのジョブコントロールシステムと言っても良いと思う。このOSSの実態を掴むために、軽く動かして見ただけだけど、これは良いツールという印象だった。 Argo workflow のインストール K8sクラスタのセットアップ Argo workflowは、コンテナ化されたバッチジョブのステップを実行するので、コンテナのエクゼキューターを指定できるようになっている。 デフォルトの設定では、dockerになっており、ソケットのパスが決まっている。 これらをdocker以外に変更しても動くが、成果物データをストレージに保存出来ないIssueがOpenとなっている。しかし、dockerと言っても、containerdをアクセスするだけのようなので、ソ

Spring Boot入門の本を読むと、Maven と Gradle でのビルドの方法が併記されているものが殆どだ。Gradle は Mavenとどう違うのだろうか？ なんで Gradle 使わないといけないのか？ とふつふつと疑問が湧いてくる。しかし、どちらのホームページを読んでも、非常に多くのことができることを漠然と書いてあるだけで、具体的な違いを簡単に理解させてもらえない。 そこで、動かしながら、それぞれの基本と両者の違いを確認したメモである。ついでに、make と ant も整理してみた。 make (メイク) makeコマンドは、プログラムのビルド作業を自動化する。 コンパイル、リンク、インストール等のルールを記述したテキストファイル (Makefile) に従って、これらの作業を実行する。 C/C++言語だけでなく、Java言語にも適用することができる。 構成ファイル: Mak

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? エッジコンピューティングは、IoT機器などの情報の発生源や利用者の近くに、サーバーなどを分散配置することによって、クラウドに集中する方式よりも、素早くデータ処理結果を活用するコンピューティングモデルである。 クラウドなどのデータセンターを中心として考えた場合、情報の発生源や利用者は、インターネットには接続されているが、ネットワークの末端に位置すると見なすことができる。 この末端でデータ処理することから、エッジコンピューティングと言い表される。クラウドコンピューティングではデータセンターで集中処理することに対して、エッジコンピューティング

JenkinsとKubernetesを連携させてCIパイプラインを構築する時に、一番悩むの点は、いろいろな方法があるために、何を選択して良いか解らない。そして、実際に実装を進めると、様々な問題が発覚して、時間がかかってしまうことがある。 Jenkinsのプラグインで、Dockerに関するものだけでも約20種類、Kubernetesの関係するもので 約17種類もある。しかも、これらが問題なく動作するという保証も無い。筆者が経験したケースでは、資料が作られた時期から時間が経過すると共にプラグインが更新され、新たな問題が生じてしまい、動作しなくなっているなどがあった。そして、ドキュメントは、Jenkinsに詳しいエンジニア向けに書かれているために、普段触り慣れないJenkins初心者には難解な内容となっていることもある。 そして、Kubernetes上でJenkinsを動作させる場合にも問題が多

OKD4 が 2020年7月にGAとなった。ドキュメントを読むかぎり、Minishiftとは大きく異なり、ハイブリッドクラウドを意識した内容となっているので、実際に動かしてみることにした。 OKD4 は、The Origin Community Distribution of Kubernetes の略とされる(なんか順番違うけど)。OpenShift v4 の大部分の上流となっているオープンソースプロジェクト Origin から配布される。これは Apache License, Version 2.0. で配布されるオープンソースである。 ダウンロード パソコンに、ocコマンドがインストールされていれば、以下のコマンドでダウンロードすることができる。 バイナリをブラウザでダウンロードする場合は、https://github.com/openshift/okd/releases から入手で

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Argo(アルゴ）は、2020年4月にCNCFのインキューベーション・プロジェクトになった。筆者が所属するIBMでも、注目のプロジェクトで適用が始まっているので、その概要について調べてみた。 アルゴとは アルゴプロジェクトは、ワークフロー、デプロイ、ロールアウト、およびイベントなど、ジョブやアプリケーションをデプロイし、実行するためのKubernetes-ネイティブツールのセットだ。継続的デリバリー、累進的デリバリーなどの GitOps パラダイムによって、KubernetesでMLOps つまり機械学習のDevOps基盤を推進する。

この記事は、TektonパイプラインでコンテナをビルドしてK8sクラスタへデプロイする方法の続きで、次図の左上のデベロッパーが git push するだけで、右端のKubernetesクラスタの環境にデプロイされるまでの途中工程を Tekton Trigger と Pipeline を組み合わせて実現する。前回の記事は、図後半のパイプラインの構築したものであった。今回は前半のGitリポジトリのWebhookを受けて、パイプラインを実行する部分を重点に書いていく。 環境設定 どのクラウド上でもTektonは動作するので、下記 kubectl get node でワーカーノードがリストされた状態から、記事の内容は始める。GitHubからのWebHookを受ける部分で、イングレスコントローラに割り当てられたドメインとシークレットを参照するために、IBM Cloud 固有のコマンドを実行する部分が

ROOK Ceph の永続ストレージを利用したアプリケーション利用としてログ分析基盤を導入してみたい。これまで ROOK Ceph のブロックストレージを検証したメモのQiita記事でROOK Cephのストレージを構築して、永続ストレージを利用したアプリケーションとしてKubernetesの監視#1 Promethus & Grafana on ROOK Cephでメトリックス監視を構築した。この記事では、ログ分析 エラスティックサーチ(Elastiecsearch) とブラウザUI キバナ (Kibana)を導入してみたい。 Elastiecsearchとサンプルアプリの名前空間作成 Elastiecsearch や　Guestbook など複数のアプリケーションを Kubernetesクラスタへデプロイして運用する場合、必ず専用の名前空間を作成して、その中で動作させるのが良い。名前空

このことから、podman は Red Hat がオープンソース・プロジェクトとして、発展途上であると見なされ、dockerコマンドを置き換えるまでに熟成されるには、もう少し時間が必要と考えられる。 (3) OCIに準拠するコンテナイメージの開発、管理、および、コンテナとして実行 Docker Hubに登録されたコンテナを実行すること、podmanでビルドして、レジストリに登録したイメージを、dockerコマンドで実行することも可能であり、互換性に問題はないと見られる。 (4) デーモンレスのコンテナエンジン podman は、Dockerデーモンの様な root で動作するデーモンを必要としない。つまり、podman コマンドだけで、デーモンの助けを必要とせずにコンテナを実行できる。 (5) コンテナはルートレスモードで実行可能 ルートレスのコンテナは、それらを起動したユーザーよりも多く

The Twelve-Factor Appは、Heroku を想定して書かれたもので、コンテナをベースとしたオーケストレーターに適用するには、少々読み替えが必要となる。その様な適用法の記事がインターネット上あるので、参考資料に挙げておく。 参考資料 : immutable infrastructure, https://searchitoperations.techtarget.com/definition/immutable-infrastructure How do you build 12-factor apps using Kubernetes?, https://www.mirantis.com/blog/how-do-you-build-12-factor-apps-using-kubernetes/ Kubernetes & 12-factor apps, https://m

Docker/Kuberneresの学習本を書きました。15ステップあるのですが、1ステップ完結型なので好きな所から学習できます。https://amzn.to/2mgCRya Follow

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 開発者に愛用されているVagrantとVirtualBoxの環境を作っている Mac や Windows10の環境で、MiniShiftを簡単に動かす方法について書きました。それから、「15Stepで習得 Dockerから入るKubernetes コンテナ開発からK8s本番運用まで」の執筆動機やMiniShiftを含めなかった諸事情について、内訳話を少々書きました。 注意：記事の内容は、個人の見解であって、所属する会社を代表するものではありません。Red Hat CodeReady Containers (OpenShift4) のイン

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? コンテナイメージのレジストリでは、脆弱性検査の実装が当たり前になっている。企業でKubernetesなどコンテナを使用するにあたって脆弱性対策がどれほど重要なものか理解するために、脆弱性検査や、関連する国際的な標準について整理した。 脆弱性（ぜいじゃくせい）とは 脆弱性とは、プログラムの動作の不備を悪用される情報セキュリティ上の弱点である。つまり、ソフトウェア上の問題が原因となって生じた欠陥であり、セキュリティホールとも呼ばれる。当然、ソフトウェア開発者は、脆弱性を産まないように細心の注意を払ってコード開発を進めるが、開発者が利用するオ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Dockerコンテナは、プロセスの一種であり、コンテナホストのカーネルを共有するために、セキュリティ上のリスクがある。このコンテナの動作原理上のリスクを軽減するために、さまざなの試みが実施されている。そこで、Dockerコンテナの基本的仕組みから、コンテナの隔離性を高めるためのOSSプロジェクトを整理する。 Dockerコンテナの仕組みとセキュリティ Dockerコンテナの仕組みの基本は、次の3点である。 Kernel namespaces (カーネル・ネームスペース) Control groups (コントロール・グループ) Linu

Red Hat General Container Image Guidelinesは、非常に重要で良い題材を扱っているにも関わらず、説明が不足したりして、勿体無い印象を受けた。そこで、読み解いてみることにした。この記事は、読者の理解であり誤った内容を含む可能性があります。もし発見されたら、是非コメント頂ければ幸いです。 コンテナ・イメージのビルド・ベストプラクティス コンテナ・イメージのビルドについて、ベスト・プラクティスとなる記事を、以下にリストする。基礎的なことであったり、関連の深いことなので、見比べながら、理解する参考にした。 Docker Docs Best practices for writing Dockerfiles Dockerfile を書くベスト・プラクティス 日本語訳 Red Hat General Container Image Guidelines Guida

IBM Cloud の Kubernetes サービスに 2019年7月で Red Hat OpenShift が加わった。このOpenShiftは、Red Hat がサブスクリプションでサポートするソフトウェアであり、Kubernetesの本来の機能に加えて、Red Hat の魅力的な機能が、たくさん追加されている。 その一端を知るために、IBM Cloud のOpenShift チュートリアルを実行しながら、KubernetesとOpenShiftの違いを確かめたメモである。 本メモは、OpenShift on IBM Cloud をデプロイした後に、oc login が成功して、ocコマンドが実行できる状態からの開始を想定している。oc login までの手順は、OpenShiftクラスタ管理画面のタブ「アクセス」に従ってセットアップできるので省略する。 バージョンの表示 最初にOp

オペレーター(Operator)は、約3年前にCoreOSから発表[11][12]され、人間のオペレーターの知識をコード化するといった構想が注目を浴びた、しかし、その実態の難解さが障壁であった。それから最近になって Red Hat社のOpenShift4の発表において、オペレーターの推進が前面に押し出され、今年初めには、さらに後押しするように、主要クラウドベンダーと協力してOperatorHub.io を推進することが発表[13]された。IBM Cloud でも Red Hatと統合とOpenShiftの推進に加えて、オペレーターを推進する姿勢が強くなっている。 これは、そもそもオペレーターとは？、その実態についての疑問、現在の目標達成レベルなどについて、調べた結果のメモである。この内容は、筆者が個人的に調べで、まとめた内容である、その中には誤りを含む可能性もあるので、ご留意いただきたい。

k8sクラスタのノードの一つが、ハードウェア障害などでダウンした場合の振る舞いについて検証した記録です。 検証システムの構成 Kubenetes v1.10 クラスタをVagrantで構築したメモのVagrantで構築したk8sクラスタを利用して、障害時の振る舞いについて、調べてみました。 マスターノードであるk8s1にもNodePortが動作していますから、このk8s1をロードバランサーに見立て、HTTPクライアントからk8s1のTCP31514をアクセスして、k8s2とk8s3のNginxのウェブサーバーをアクセスします。 そして、 k8s2 仮想サーバーの模擬障害としてシャットダウンした場合のクライアント視点での動作、ポッドのマイグレーションについて検証します。 正常稼働の状態 初期状態として、すべてが正常に稼働している状態の動作を確認しておきます。 この画面の表示は、上から順に、以

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? このThe Twelve-Factor App ( https://12factor.net/ja/ ) は、Heroku創業メンバーの一人である Adam Wiggins によって書かれたウェブ・アプリケーションやSaaSを作り上げるためのメソッドです。 これは著者の様々な実務経験をもとに、まとめられたもので、プログラミング言語、データベースなどのサービスの種類に依存せず応用することができる優れたメソッドです。 多くのデベロッパーが、このメソッドの参照を推奨しています。 もともと、The Twelve-Factor Appは、アプリケ

Kubernetesクラスタに Helmを使ったセットアップが増えているように思います。そこで、Helmコマンドの基本的な使い方を整理しました。 Helmの3大コンセプト Helmは、以下の3点を押さえておくと、理解しやすくなります。 (1) チャートは、ヘルムのパッケージである。 チャートには、ツール、アプリケーション そして サービスなどをKubernetes クラスタで実行に必要なすべてのリソース定義が入っている。類似の概念として、RedHat系Linuxのyumコマンド、Debian系Linuxのaptコマンドなどがある。 (2) リポジトリは、チャートを集め共有するための場所である。 類似の概念では、Perl言語のCPANリポジトリ、Fedora Package Database などがあるが、Kubernetes 用である。 (3) リリースは、Kubernetes上で実行され

AWS と IBM Cloud の二つのクラウドで、Terraform 仮想サーバーをプロビジョニングして、マルチクラウド化ツールの実態を体験して理解したいと思い、前回、IBM Cloudで作成した Terraform の構成ファイルを AWS EC2 用に書き直して、検証をおこないました。 この記事は、Terraform + Cloud-init + Ansible で IBM Cloud VSIプロビジョニング自動化の記事のAWS版です。 Terraform の詳細なコードは、takara9/terraform-aws-ec2 にあります。Terraform の実行環境は、takara9/vagrant-terraformを想定しています。 次のように、GitHubからクローンしたディレクトリで、ファイル名を挙げながら、どのように対応したのかを記述しておきます。 ~/terraform

k8sクラスタ外部のトラフィックを受け入れて、負荷分散など実行しながら、ポッドへアクセスを分散させる方法です。 vagrantの仮想サーバーで、k8s v1.10のクラスタを動作させて検証した５回目の記事で、これまでの記事を列挙しておきます。 Kubenetes v1.10 クラスタをVagrantで構築したメモ K8s on Vagrant, Node障害時の振る舞いについての検証記録 K8s on Vagrant, ダッシュボードのセットアップ K8s on Vagrant, NFS 永続ボリュームの利用メモ Ingressとは? ノード横断のポッド・ネットワーク上のサービスやアプリケーションは、プライベートIPアドレスがアサインされますから、ルーティングする事が出来ないために、インターネットのクライアントと通信することができません。 このため、Ingressは、クラスタ内のサービス（

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

自己研鑽で学んだことのメモです。 準備事項 kubectlをインストールする AWS CLIをインストールする aws-iam-authenticator をインストールする キーペアを作成する サービスロールを作成する クラスタVPCを作成する インストールするものから、先に進めていきます。EKSは、日本から一番近いオレゴンのリージョンを利用しました。 1.kubectlコマンドのインストール 筆者が試したところ、CNCFからダウンロードした kubectl コマンドでも、利用できたので、特別にビルドされたものではないようです。 https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/configure-kubectl.html ホームディレクトリに、ディレクトリ aws-eks を作成して、ダウンロードした kubectl を保存し

KubernetesでHTTPSを利用する方法として、イングレスに証明書をセットすることで、コンテナやポッドの設定を追加せずに、HTTPSを利用できるようになります。 しかし、パフォーマンスやスケールの観点では、イングレスコントローラーに負荷が集中するために、ポッドのレプリカ数を増やしても、思ったように性能が出せないなどの課題に直面することになります。 (IBM Cloudでは ALBと呼ばれています、) そこで、外部のロードバランサーやイングレスにも頼らず、コンテナの中で、TLS暗号を終端して、スケールさせるという方法について、検討する中で、テスト中にサーバー証明書で困ったので、書き残すことにしました。 この記事は、NginxのコンテナでHTTPSでサービスを公開するには、すなわち、TLS暗号を利用する方法のメモです。TLS暗号のためには、証明書が必要で、次の３つの方法で作成することがで