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コマンドがインストールされていれば、以下のコマンドでダウンロードすることができる。 $ oc adm release extract --tools quay.io/openshift/okd:4.5.0-0.okd-20

この記事は、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クラスタへデプロイして運用する場合、必ず専用の名前空間を作成して、その中で動作させるのが良い。名前空

クラウドネイティブを推進する約500団体が参画する CNCF (Cloud Native Computing Foundation)に、クラウドネイティブの定義が公開されている。これは、IT業界で働く者の基礎知識であると言えるので、クラウドネイティブの定義を詳細に調べた結果を以下にまとめる。 CNCFとは CNCFは2015年7月に発表され、約50社が集まり2016年1月に正式発足した。最初の発表から4年後2019年11月のメンバーは約500団体で、大手クラウド事業者、ミドルウェア企業、ハードウェア製造企業、オープンソース・ソフトウェア企業、大学、その他非営利団体などが加入している。 CNCFは、The Linux Foundationの下で運営され、クラウドとコンテナに関連する横並びの活動として、Cloud Foundry Foundation、Xen Project, Open Con

クラウドネイティブを推進する約500団体が参画する CNCF (Cloud Native Computing Foundation)に、クラウドネイティブの定義が公開されている。これは、IT業界で働く者の基礎知識であると言えるので、クラウドネイティブの定義を詳細に調べた結果を以下にまとめる。 CNCFとは CNCFは2015年7月に発表され、約50社が集まり2016年1月に正式発足した。最初の発表から4年後2019年11月のメンバーは約500団体で、大手クラウド事業者、ミドルウェア企業、ハードウェア製造企業、オープンソース・ソフトウェア企業、大学、その他非営利団体などが加入している。 CNCFは、The Linux Foundationの下で運営され、クラウドとコンテナに関連する横並びの活動として、Cloud Foundry Foundation、Xen Project, Open Con

コンテナイメージのレジストリでは、脆弱性検査の実装が当たり前になっている。企業でKubernetesなどコンテナを使用するにあたって脆弱性対策がどれほど重要なものか理解するために、脆弱性検査や、関連する国際的な標準について整理した。 脆弱性（ぜいじゃくせい）とは 脆弱性とは、プログラムの動作の不備を悪用される情報セキュリティ上の弱点である。つまり、ソフトウェア上の問題が原因となって生じた欠陥であり、セキュリティホールとも呼ばれる。当然、ソフトウェア開発者は、脆弱性を産まないように細心の注意を払ってコード開発を進めるが、開発者が利用するオペレーティングシステムのライブラリやパッケージに含まれることもある。そのような事情から、開発者の責任範囲外に原因がある場合も多くある。 潜在的な脆弱性を突いた新たなクラッキングの手口が、時間の経過ともに発見される。そのことから、開発当初はコードに脆弱性は無い

Dockerコンテナは、プロセスの一種であり、コンテナホストのカーネルを共有するために、セキュリティ上のリスクがある。このコンテナの動作原理上のリスクを軽減するために、さまざなの試みが実施されている。そこで、Dockerコンテナの基本的仕組みから、コンテナの隔離性を高めるためのOSSプロジェクトを整理する。 Dockerコンテナの仕組みとセキュリティ Dockerコンテナの仕組みの基本は、次の3点である。 Kernel namespaces (カーネル・ネームスペース) Control groups (コントロール・グループ) Linux kernel capabilities (Linux カーネル・ケーパビリティ) これら3点について、セキュリティの観点から確認していく。 カーネル・ネームスペース docker runを使ってコンテナを起動すると、バックグラウンドで、カーネル・ネームス

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

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

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

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

このThe Twelve-Factor App ( https://12factor.net/ja/ ) は、Heroku創業メンバーの一人である Adam Wiggins によって書かれたウェブ・アプリケーションやSaaSを作り上げるためのメソッドです。 これは著者の様々な実務経験をもとに、まとめられたもので、プログラミング言語、データベースなどのサービスの種類に依存せず応用することができる優れたメソッドです。 多くのデベロッパーが、このメソッドの参照を推奨しています。 もともと、The Twelve-Factor Appは、アプリケーションをHerokuのプラットフォームに適合するためのメソッドとも見なせますが、コンテナ技術を利用したアプリケーションにも共通点が多く、Kubernetesでアプリケーションを運用するケースでも有用と考えます。 そこで、このメソッドをK8sへ適用するために

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

k8sのジョブの利用方法で、Queue with Pod Per Work Item (作業項目毎のポッドのキュー) の意味が良く分からないので、リンク先のCoarse Parallel Processing Using a Work Queue を検証して、その意図する処を確かめたメモです。 概要 目的とする処理方式を図にすると、次の様になります。 主題であるバッチ型処理は、右下の赤い四角形で、RabbitMQ からデータを取得して、バッチ・ジョブを実行します。 この図で Depolyment or Replication Controller と表記した箱で、左上がRabbitMQへのデータの投入側になります。そして、真ん中の箱が、RabbitMQのコンテナが動作するポッドです。その上に描いた紫の小さな箱が、RabbitMQを他のデプロイメントやジョブからアクセスできる様にするための

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Brendan Burns, David Oppenheimerらの論文「Design patterns for container-based distributed systems」を読んで、コンテナを活用したシステム設計や開発に、とても有用と感じたので、図を中心にした要約にしてみた。 要約内容に誤りや理解不足な部分もあると思うので、原文も参照していただきたい。また、自身の理解のために、論文中に無い図を加えた点、独自の注釈も加えている。 背景 コンテナ化されたソフトウェアコンポーネントから構築されたマイクロサービスアーキテクチャの人

ORACLEならsqlplus、DB2ならdb2、MySQLなら mysql、PostgreSQLならpsql、では Bluemix Db2 Warehouse on Cloud (旧dashDB）へ繋ぐには、どうしたら良いの？　ということで調べたメモです。 Macの開発環境から、Bluemix の IBM Db2 Warehouse on Cloud へ、コマンドラインツール clpplus から、暗号通信でアクセスするための情報を整理したものです。 この記事では IBM Db2 Warehouse on Cloud は長いので 愛称として dashDB として記載します。 IBM Db2 Warehouse on Cloud (愛称dashDB）とは dashDB は、分析機能を兼ね備えたDBaaSで、地理空間データなどの特殊な型のデータを含むリレーショナル・データを保存することができ

session(options) express-sessionはoptionsオブジェクト内のこれらのプロパティを受け入れます。 cookie セッションID Cookieの設定オブジェクト。デフォルト値は {path： '/'、httpOnly：true、secure：false、maxAge：null} です。 このオブジェクトで設定できるオプションは次のとおりです。 cookie.domain Domain Set-Cookie属性の値を指定します。デフォルトでは、ドメインは設定されていません。ほとんどのクライアントは、現在のドメインのみに適用するCookieを考慮します。 cookie.expires Expires Set-Cookie属性の値にDateオブジェクトを指定します。デフォルトでは、有効期限は設定されていません。ほとんどのクライアントはこれを「非永続Cookie」と