サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
中東情勢
qiita.com/MahoTakara
この記事は、Libvirt と Open vSwitch を使って仮想ネットワークを検証したメモである。 Libvirt は、製品名 Red Hat Enterprise Linux virtualization として、サブスクリプション契約で利用することができる。Open vSwitch は Red Hat OpenStack、Red Hat OpenShift、Red Hat Virtualization の実現要素として組み込まれている有用な技術であり、使用には同様の制約がある。 しかしながら、LibvirtとOpen vSwitchは、OSSライセンスで提供されるプロダクトのため、Ubuntu Linux でも利用できる。そこで、これらを利用して仮想ネットワークを構築して検証した。仮想ネットワークとは、ソフトウェアによって実現するネットワークであり、物理ネットワークの上に構築する
アルゴ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
エッジコンピューティングは、IoT機器などの情報の発生源や利用者の近くに、サーバーなどを分散配置することによって、クラウドに集中する方式よりも、素早くデータ処理結果を活用するコンピューティングモデルである。 クラウドなどのデータセンターを中心として考えた場合、情報の発生源や利用者は、インターネットには接続されているが、ネットワークの末端に位置すると見なすことができる。 この末端でデータ処理することから、エッジコンピューティングと言い表される。クラウドコンピューティングではデータセンターで集中処理することに対して、エッジコンピューティングは拠点に配置された機器とクラウドのサーバーとの分散処理である。 データの発生源やユーザーの近くでデータ処理する利点として、5つ上げることができる。 応答の早いリアルタイムな処理 通信コストの削減と高効率 信頼性 スケーラビリティ プライバシーとセキュリティ
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
Argo(アルゴ)は、2020年4月にCNCFのインキューベーション・プロジェクトになった。筆者が所属するIBMでも、注目のプロジェクトで適用が始まっているので、その概要について調べてみた。 アルゴとは アルゴプロジェクトは、ワークフロー、デプロイ、ロールアウト、およびイベントなど、ジョブやアプリケーションをデプロイし、実行するためのKubernetes-ネイティブツールのセットだ。継続的デリバリー、累進的デリバリーなどの GitOps パラダイムによって、KubernetesでMLOps つまり機械学習のDevOps基盤を推進する。 アルゴ プロジェクトは、CNCFが支援するプロジェクトであり。この活動は複数あるが、本記事では、主要な4つのグループを取り上げる。 アルゴ ワークフロー (Argo Workflow) アルゴ CD (Argo CD (Continuous Developm
この記事は、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) コンテナはルートレスモードで実行可能 ルートレスのコンテナは、それらを起動したユーザーよりも多く
クラウドネイティブを推進する約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
Docker/Kuberneresの学習本を書きました。15ステップあるのですが、1ステップ完結型なので好きな所から学習できます。https://amzn.to/2mgCRya Follow
開発者に愛用されているVagrantとVirtualBoxの環境を作っている Mac や Windows10の環境で、MiniShiftを簡単に動かす方法について書きました。それから、「15Stepで習得 Dockerから入るKubernetes コンテナ開発からK8s本番運用まで」の執筆動機やMiniShiftを含めなかった諸事情について、内訳話を少々書きました。 注意:記事の内容は、個人の見解であって、所属する会社を代表するものではありません。Red Hat CodeReady Containers (OpenShift4) のインストールのメモも合わせて、参照頂ければと思います。 MiniShiftについて OpenShiftは、CNCFからソースコードが配布されるアップストリーム(源流)のKubernetesに、Red Hat社独自の拡張を加え、さらに、Red Hatのソフトウェア
コンテナイメージのレジストリでは、脆弱性検査の実装が当たり前になっている。企業で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
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 仮想サーバーの模擬障害としてシャットダウンした場合のクライアント視点での動作、ポッドのマイグレーションについて検証します。 正常稼働の状態 初期状態として、すべてが正常に稼働している状態の動作を確認しておきます。 この画面の表示は、上から順に、以
マルチクラウドやハイブリッドクラウドを考える上で、3大クラウドのサービス内容を勉強する機会がありました。そこで、整理のために、対応表を作成してみました。各社のすべてのサービスを網羅しているわけではないですが、仮想サーバーやオブジェクトストレージなどのコアとなるサービスを中心として表にしました。 そして、各社の中で、何処が優れ、どれが劣っているとかの比較をするものではありません。 主要なサービス名の言葉の対応を目的としたものです。 最近1ヶ月くらいで勉強したことを、外観的に整理したものなので、間違いも含まれると思います。 気づいた方は、コメントを頂けると幸いです。 後になって知ったのですが、こんな比較表より、もっと、良い資料がありましたので載せておきます。Public Cloud Services Comparison (March 18th,2019) 比較項目 AWS Azure GCP
このThe Twelve-Factor App ( https://12factor.net/ja/ ) は、Heroku創業メンバーの一人である Adam Wiggins によって書かれたウェブ・アプリケーションやSaaSを作り上げるためのメソッドです。 これは著者の様々な実務経験をもとに、まとめられたもので、プログラミング言語、データベースなどのサービスの種類に依存せず応用することができる優れたメソッドです。 多くのデベロッパーが、このメソッドの参照を推奨しています。 もともと、The Twelve-Factor Appは、アプリケーションをHerokuのプラットフォームに適合するためのメソッドとも見なせますが、コンテナ技術を利用したアプリケーションにも共通点が多く、Kubernetesでアプリケーションを運用するケースでも有用と考えます。 そこで、このメソッドをK8sへ適用するために
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のクラスタを動作させて検証した5回目の記事で、これまでの記事を列挙しておきます。 Kubenetes v1.10 クラスタをVagrantで構築したメモ K8s on Vagrant, Node障害時の振る舞いについての検証記録 K8s on Vagrant, ダッシュボードのセットアップ K8s on Vagrant, NFS 永続ボリュームの利用メモ Ingressとは? ノード横断のポッド・ネットワーク上のサービスやアプリケーションは、プライベートIPアドレスがアサインされますから、ルーティングする事が出来ないために、インターネットのクライアントと通信することができません。 このため、Ingressは、クラスタ内のサービス(
Node.js Expressフレームワークで、HTTPSサーバーを起動する方法の忘備録です。 Express HTTPサーバーを起動するパターン // Expressフレームワーク var express = require('express'); var app = express(); // ルート設定 app.get('/rest', function (req, res) { res.send('Hello World!'); }); // イベント待機 app.listen(3000); Express HTTPSサーバーを起動するパターン 事前準備として、DNS名を取得して証明書を取得しておきます。HTTPSサーバーと通常のHTTPサーバーとの違いは、HTTPSサーバー起動の部分です。 // Expressフレームワーク var express = require('expr
AWS初心者だけど、EKSのクラスタを作って、NodePort と ELBアクセス、EBSのPVを確認したよAWSkuberneteseks 自己研鑽で学んだことのメモです。 準備事項 kubectlをインストールする AWS CLIをインストールする aws-iam-authenticator をインストールする キーペアを作成する サービスロールを作成する クラスタVPCを作成する インストールするものから、先に進めていきます。EKSは、日本から一番近いオレゴンのリージョンを利用しました。 1.kubectlコマンドのインストール 筆者が試したところ、CNCFからダウンロードした kubectl コマンドでも、利用できたので、特別にビルドされたものではないようです。 https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/confi
KubernetesでHTTPSを利用する方法として、イングレスに証明書をセットすることで、コンテナやポッドの設定を追加せずに、HTTPSを利用できるようになります。 しかし、パフォーマンスやスケールの観点では、イングレスコントローラーに負荷が集中するために、ポッドのレプリカ数を増やしても、思ったように性能が出せないなどの課題に直面することになります。 (IBM Cloudでは ALBと呼ばれています、) そこで、外部のロードバランサーやイングレスにも頼らず、コンテナの中で、TLS暗号を終端して、スケールさせるという方法について、検討する中で、テスト中にサーバー証明書で困ったので、書き残すことにしました。 この記事は、NginxのコンテナでHTTPSでサービスを公開するには、すなわち、TLS暗号を利用する方法のメモです。TLS暗号のためには、証明書が必要で、次の3つの方法で作成することがで
ポッドの中で二つのコンテナが動作して、ストレージを共有しながら動作するポッドを指して、サイドカー(Sidecar) と呼ぶ様です。 この様なサイドカーの主な用途として、ログを転送する目的や、ウェブ・アプリのコンテンツを共有する目的があります。この様な目的の場合、外部の永続ディスクを利用するとディスクアクセスのためのiSCSIがボトルネックとなる恐れがあります。 一方、ポッドを収容するノードの仮想サーバーのストレージはSSDが使われている(IBM Cloudのケース)ため、永続ストレージを利用せず、ノードのストレージを利用する事が得策と思います。 比較の図 IBM Cloud のワーカーノードは Local Disk(SSD)が利用される そこで、サイドカーを構成する方法について、そして、特徴について確認しました。 サイドカー構成のポッド作成 一つのポッドに2つのコンテナを設定するYAMLで
次のページ
このページを最初にブックマークしてみませんか?
『@MahoTakaraのマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く