Azure CLI 2.0 でサービスプリンシパルが簡単に作れるようになっていた - しばやん雑記
個人的に Azure で一番わかりにくいのが認証回りです。特に Azure Active Directory を使ってディレクトリが追加されたタイミングで、さらにわけが分からなくなりました。 例えば Azure に対する操作を自動化したい時に Azure にログインするアカウントを使うわけにはいかないので、別に操作権限を絞ったアカウントを用意したいわけです。一応サービスプリンシパルを使うことになってますが、これの作成が非常にわかりにくい。 自動化のためにスクリプトから使いたいだけなのに、何故か URL が 2 つ要求されるんですよね。それぞれ何を指定すればいいのかわからないので、明らかに説明が足りてないです。 PowerShell を使うと 3 行みたいですが、ポータルだとそもそも作れるのかどうか怪しいです。 そんな感じでサービスプリンシパルを作るのが非常に嫌だったのですが、今 Pytho
GitHub - hinemos/hinemos: Hinemos core components
Hinemos can be installed with a single command. For installing the Manager RHEL 7.x $ rpm -ivh https://github.com/hinemos/hinemos/releases/download/v7.1.1/hinemos-7.1-manager-7.1.1-1.el7.x86_64.rpm RHEL 8.x $ rpm -ivh https://github.com/hinemos/hinemos/releases/download/v7.1.1/hinemos-7.1-manager-7.1.1-1.el8.x86_64.rpm RHEL 9.x $ rpm -ivh https://github.com/hinemos/hinemos/releases/download/v7.1.1
ネットワークインフラは、イミュータブルなものになれるのか？ | DevCentral
Please find the English language post, by Lori MacVittie, from which this was adapted here. イミュータブルインフラストラクチャ、私は使い捨て可能なインフラストラ チャと呼んだ方がふさわしいと思うのですが、この1年でDockerとコンテナ化技 術の成功によって再び注目を浴びました。また、DevOpsは、自動化と関連する 使い捨て可能なインフラストラクチャの概念と、取得から構成までのすべてを 自動化して、アプリケーションデータパスのあらゆるものを提供する「テンプ レート」の使用を復活させるうえで役割を果たしてきました。 技術トレンドが、昨今のビジネスの核であるアプリケーション開発から、アプ リケーションデータパスの終点であるネットワークに必然的に移行して
インフラ系技術の流れ - Gosuke Miyashita
ここ最近のインフラ系技術の流れがおもしろいなー、と思ったので、Puppet が出た辺りぐらいから、振り返って整理してみる。殴り書きなので、後から修正したり書き加えたりするかも。特に後半の方は、あまり考えが整理できてない。 最近のウェブ界隈での「インフラ」という用語の使われ方には、色々異論もあるようだけど、ここではごく最近使われるようになってきた、OS からミドルウェアといったソフトウェアレイヤーを指す言葉としてのインフラについて触れる。（英語圏でも同様の意味で使われているようなので、ある程度市民権を得たと言っても良さそうだし。） プロビジョニングレイヤー まず、前提知識としてプロビジョニングレイヤーと自分が勝手に呼んでるものについて整理。 Chef や Puppet は「プロビジョニングフレームワーク」とも呼ばれているが、以下の議論をより厳密にするために、Lee Thompson 氏による
Ansible Tower by Red Hat のご紹介
Ansible Tower by Red Hat のご紹介 1. Ansible Tower by Red Hatのご紹介 Red Hat 株式会社 2017-03-21 2. 2 Agenda 1. Ansible 2. Ansible Tower 3. Ansible Towerの販売 4. Ansible Towerの導入事例 3. IT運用自動化の課題 共通認識「IT運用には定型作業が多いから自動化したいね」「簡単 に自動化できるところもあるよね」 ↓やろう↓ ● 関係者のスキルレベルにギャップ → 翻訳が必要 – スクリプトで自動化したものをExcelでレビュー – メンテナンスも二重管理に ● 企業内に多様なハードウェア・ソフトウェアが存在 – 「自動化のためのAPI」があるものは多いが利用方法はバラバラ – 複数製品にまたがる自動化が難しい – ある方法で自動化すると特定ベン
Infrastructure as Code 再考 - Gosuke Miyashita
Infrastructure as Code という言葉が現れてから少なくとも8年ほど経過しており、この言葉もすっかり定着したように見えるが、Martin Fowler 氏が最近自身のブログで Infrastructure as Code について触れており 、また、氏の同僚である Kief Morris 氏が O'Reilly Media から Infrastructure as Code という本を出す（現在 Early Relase 版や Free Chapters が入手できる）ようなので、このタイミングで改めて Infrastructure as Code について、その歴史を振り返るとともに、現在の状況について整理してみようと思い、このエントリを書くことにした。 内容的には、以前書いた インフラ系技術の流れ と若干重複してる部分もある。 そういえば日本でも最近、サーバ/インフラ
Immutable InfrastructureとChefと冪等性の話 - プログラマでありたい
最近話題になっているImmutable Infrastructure（イミュータブル・インフラストラクチャ/サーバ）。あんまりよく解っていないので、整理してみました。 Immutable Infrastructureとは？ そもそもImmutable Infrastructureとは、何でしょう？極論すると、「稼働中のサーバの構成管理をやめて、サーバを使い捨てにしよう」という考え方です。これだけ言われても、さっぱり解らないと思います。 まずは従来の考え方。Mutable Infrastructureというのか、既存のサーバに変更を加えていくことが前提になります。 それに対して、Immutable Infrastructure。直訳すると変化しないインフラとなります。どういうことかと言うと、サーバ構成（ミドル・アプリ）を変更したい場合は新規にサーバを立ちあげ、そこに既存の機能と新規の機能を加
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
