Terraform職人のためのOpenTofu入門 - Qiita
この記事は クラウドワークス Advent Calendar 2023 シリーズ1 の 4日目の記事です。 はじめに 「父さんな、Terraform職人やめてお豆腐職人で食っていこうと思うんだ」と言いたいだけの @minamijoyo です。 2023年8月HashiCorpはこれまでMPL2のOSSライセンスで公開していた主要製品をBSL(Business Source License)に変更することを発表し、Terraformはv1.6.0からOSSではなくなりました。 このライセンス変更を受けて、OSS版のTerraformを求める人たちで、MPL2時点のコードベースからforkしたOpenTofuの開発が進められています。 HashiCorpのBSLは、実質的に競合他社の商用利用に制限をかけたもので、ほとんどの一般的なユーザに直接的な追加の制限はありませんが、間接的にTerrafo
tfupdateでTerraform本体/プロバイダ/モジュールのバージョンアップを自動化する - Qiita
はじめに Terraform職人あらためシニアHCLエンジニア（？）の @minamijoyo です。 最近はHCL(HashiCorp Configuration Language)のパーサで遊んでいます。Terraformの設定をパースしていいかんじに書き換えることができるようになると夢が広がりますよね？ そんな個人的な趣味の産物として、Terraform本体/プロバイダ/モジュールのバージョン制約をいいかんじに一括で書き換えてくれる tfupdate というツールを書いたので紹介します。 これをCIとかジョブスケジューラで流せば、毎日最新版をチェックして、差分があれば自動でバージョンアップのPull Requestを生成したりできます。つまり、「ぼくのかんがえたさいきょうのTerraform版Dependabot」ができるのだ。 ※この記事は クラウドワークス Advent Cale
TerraformでIAMポリシーのJSONに変数を埋めたい場合はaws_iam_policy_documentを使う - Qiita
TL;DR TerraformでIAMポリシーのJSONに変数を埋めたい場合はaws_iam_policy_documentを使えばよい サンプルコードはTerraformでKMSキー作った時に、アクセス権限の管理をIAMグループで管理する例 aws_iam_policy_documentのドキュメントはこちら => AWS_IAM_POLICY_DOCUMENT サンプル KMSのキーARNを変数参照で埋め込んだIAMポリシー作って適当なIAMユーザ/グループ/ロールに付与するtfファイルこんなかんじ data "aws_iam_policy_document" "kms_hoge" { statement { sid = "AllowUseOfTheKey" actions = [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms
Terraform職人入門: 日々の運用で学んだ知見を淡々とまとめる - Qiita
はじめに この記事は CrowdWorks Advent Calendar 2017 の8日目の記事です。 Terraform職人の @minamijoyo です。Infrastructure as Codeしてますか？ インフラのコード管理に Terraform を使い始めて2年ちょっと、本番環境で運用していると日々色んな学びがあるので、Terraformやってみた系の入門記事では語られない、現場の運用ノウハウ的なものを共有してみようかと思います。 Terraformを使い始めた or 使っている人が、こんなときどうするの？っていうときに参考になれば幸いです。 書き始めたら超長文になりました。概要は以下のとおりです。 公式ドキュメントを読もう tfファイルを書く技術 インデントを揃える 組み込み関数に親しむ lifecycleブロックを使う リソースの差分を無視する リソース再生成のとき
Terraform職人再入門2020 - Qiita
data "aws_caller_identity" "current" {} output "account_id" { value = data.aws_caller_identity.current.account_id } 若干補足しておくと、 "${}" 自体が廃止されたわけではなく、今でも文字列の中に変数を埋め込む場合には必要ですが、式が変数の参照しか含まない場合は不要で、v0.13.4以降は冗長な書き方は警告が出ます。ちなみにv0.14のfmtはもう一歩踏み込んで、この書き方を自動で修正するようになりました。古いサンプルコードを雑にコピペできるようになってべんり。 Terraformではなく汎用的なHCLそのものの仕様を調べたいときは、 hashicorp/hcl にありますが、本稿執筆時点ではデフォルトのmasterブランチはまだHCL1であることに注意して下さい。 HCL
logrageではRails.loggerのログ出力がJSON形式にならない問題 - Qiita
はじめに RailsログをJSON形式にしたいだけなんですが、解決方法が意外とめんどくさかったので、ググってたどり着いた誰かのためにメモを残しておきます。 「Railsログ JSON」で雑にググるとlogrageというgemをいれるとよさそうな感じです。 https://github.com/roidrage/lograge gem入れるだけでバーンといいかんじのJSONになることを期待したのですが、以下の記事に書いてあるとおり、このgemはコントローラのアクセスログや例外しかJSON形式で出ません。 https://qiita.com/amanekey/items/b921ef73d871dac299eb おもむろに Rails.logger.info("foo") とかしてもJSONにならなくてそのまま出力されちゃう。 つまりこんなかんじ。 {"method":"GET","path"
envsubstを使ってDockerで設定ファイルに環境変数を埋め込めこむ汎用的なパターン - Qiita
はじめに Docker使ってるとできるだけイメージは共通化して、設定ファイルはマウントで差し込み、環境ごとの設定差分は環境変数で埋め込む方向になってきます。 しかしながら、設定ファイルに環境変数を直接埋め込めるかは対象のソフトウェアの実装次第で、例えばfluentdは設定ファイルで環境変数を直接埋め込めるけど、nginxは環境変数を直接埋め込めなかったりします。 で、よくやるのは entrypoint.sh みたいなのを作って起動時にsedするという原始的な方法もあるけど、もうちょっとスマートな方法として、 envsubst という軽量なテンプレートエンジンを使うことで、設定ファイルに汎用的に環境変数を埋め込むことができて便利なので紹介したい。 インストール nginx:alpineには既にenvsubstコマンド入ってるので、そのまま使える。 他のイメージで入ってなければ以下の方法でイン
PowerShellでスクリーンセーバーが有効になってるか確認する - Qiita
スクリーンセーバーの設定が有効になってるか、復帰時にパスワード入力が必須になってるかチェックする処理をPowerShellで書いたので貼っておきます。 スクリーンセーバーの設定はWMI経由で root/CIMV2 の Win32_Desktop から取得できます。 ポイントとしてデスクトップの設定はユーザごとにプロファイルが分かれてるので、現在ログイン中のユーザ設定を取得して絞込をします。 function SubCheck-ScreenSaver($sleepThresholdSec){ # スクリーンセーバーの設定はユーザプロファイル単位に存在するので、現在ログイン中のユーザの設定を取得する $computername = $env:computername $username = $env:username $desktop = Get-WmiObject -Namespace "r
auditdでLinuxのファイル改竄検知を行う - Qiita
はじめに Linuxでファイル改竄検知をやろうと思ってauditdを試したメモです。 ファイルの改竄検知としては Tripwire が有名ですが、Linuxであればauditdを使うことも可能です。AmazonLinuxだとデフォルトで入ってたので、設定ファイルを書くだけで使えます。 Tripwireは予めファイルのチェックサムのデータベースを作っておいて、これをファイルを比較することで、ファイルの改竄を検知します。同じようにファイルのチェックサムベースで比較するものとしてAIDEというツールもあるようです。 一方auditdは仕組みとしてはLinuxカーネルでシステムコールを記録して、特定の条件にマッチする操作をログに出力します。なので、若干守備範囲の違うツールですが、システムコールを監視することでもファイルの変更は監視できます。 LinuxのAuditのアーキテクチャや説明などは、Re
Golangのデバッガdelveの使い方 - Qiita
はじめに Goで書いたコードデバッグするのにdelveというデバッガ使ってみたら、なかなかに便利だったので基本的な使い方をまとめておく。 delveのコードは以下のGitHubリポジトリで公開されてるんだけど、 https://github.com/derekparker/delve 使い方の説明が公式ドキュメントにあんまり書いてないので、実際に触ってみて、具体例を挙げて説明していこうかと思う。 インストール 手元の環境はMacなのでbrewで入れた。 ※他の環境の場合は以下の公式ドキュメントを参照して下さい。 https://github.com/derekparker/delve/tree/master/Documentation/installation
Docker multi stage buildで変わるDockerfileの常識 - Qiita
Dockerイメージのサイズを1バイトでも削りたい皆さんに朗報です。 もうすぐリリースされるDocker 17.05でmulti stage buildという機能が導入される予定です。 こいつはこれまでのDockerfileの常識を覆す革新的な機能なのです。 Docker 17.05は本稿執筆時点では2017/05/03リリース予定となっており、現在はRC版が出てるので、気になる新機能を一足早くで試してみた。(2017/05/07追記:最終的に2017/05/04に正式リリースされました) とりあえずこの新しいシンタックスのDockerfileを見てほしい。 FROM golang:alpine AS build-env ADD . /work WORKDIR /work RUN go build -o hello main.go FROM busybox COPY --from=buil
docker-compose.ymlでcommandの引数が長いのでエスケープして改行したい - Qiita
Dockerフレンドリーなコマンドは設定ファイルなしでも引数でいろいろ挙動が指定できて便利なんだけど、 コマンドの引数の指定が長くなりがちである。 例えばoauth2_proxyはシングルバイナリで、設定ファイルもあるけど、すべての設定が引数で指定できる。 何も考えずに素朴に並べるとこんなかんじで、起動コマンドがクッソ長くなる。 version: '2' services: oauth2_proxy: image: oauth2_proxy command: /bin/oauth2_proxy -provider="github" -github-org="${OAUTH2_PROXY_GITHUB_ORG}" -github-team="${OAUTH2_PROXY_GITHUB_TEAM}" -http-address="0.0.0.0:4180" -redirect-url="htt
GolangでwebサービスのAPIを叩くCLIツールを作ろう - Qiita
はじめに この記事はGo (その3) Advent Calendar 2016の18日目の記事です。 最近Goの勉強がてら、とある社内向けWebサービスのAPIを叩くCLIツールを書いてます。 有名どころのWebサービスならたいてい既に誰かがSDKなりCLIツールを作ってたりするので、それを使ればよいと思いますが、クローズドな社内向けのWebサービスとかだと、まぁ欲しい人が自分で書くしかないですね。 で、簡単なプロトタイプが動くようになったので、このあたりで覚えたことを整理してまとめてアウトプットしておこうかなと思います。 内容的には サブコマンド形式のCLIツールを作り方 spf13/cobraの使い方 viperと連携した透過的な設定ファイルの読み込み version番号の埋め込み、Makefile pkg/errorsによるエラーの伝搬、contextを使ったタイムアウト 標準のne
Dockerコンテナ内でdockerコマンドを使う（dockerクライアントバイナリだけインストール方法） - Qiita
はじめに Dockerコンテナ内でdockerコマンドが使いたい。 このエントリは、いわゆるDocker in Dockerでネストしたいわけではなくて、同じdockerデーモンを共有する兄弟コンテナを立てたい場合の話です。 どういうユースケースかというと、 社内Heroku的なアプリケーションをDockerコンテナで動かして、Web画面をポチポチするとdocker service createしたいとか HubotをDockerコンテナで動かして、特定の発言に反応してdocker runしたいとか JenkinsをDockerコンテナで動かして、CIの実行でdocker runしたいとか Dockerを使ってるとなんでもDockerにしたい病になるので、Dockerコンテナを起動するような必要があるアプリケーションもDockerで管理したい。 作戦としては必要なイメージにdockerクラ
PowerShellでウィルス対策ソフト(Windows Defender / Microsoft Security Essentials)のリアルタイム保護状態とウィルス定義ファイル状態が最新かどうか確認する - Qiita
PowerShellでウィルス対策ソフト(Windows Defender / Microsoft Security Essentials)のリアルタイム保護状態とウィルス定義ファイル状態が最新かどうか確認するWindowsPowerShell Windowsのウィルス対策ソフト（Windows Defender / Microsoft Security Essentials）の状態が最新になってるかチェックする処理をPowerShellで書いたので貼っておく。 Windows DefenderはWindows 8以降では標準で入ってます。Windows 7だとMicrosoft Security EssentialsがMicrosoft純正で無料で使えますが、明示的にインストールしないと使えないです。 Windowsのセキュリティセンターで認識されているウィルス対策ソフトの状態は、WMI
Docker 1.13の気になる変更点と新機能 - Qiita
はじめに この記事はCrowdWorks Advent Calendar 2016 の1日目の記事です。CrowdWorksのエンジニアが毎日なにかを書きます。 Docker 1.13がそろそろ出そうです。この記事を書いてる時点ではまだRC版ですが、正式版のリリースは2016/12/8頃の予定となっているようです。(※2017/01/20追記：当初予定より１ヶ月ちょっと遅延して最終的に2017/01/18に正式版がリリースされました。) Docker 1.12ではDockerクラスタを管理するswarmがDocker Engine本体に統合されましたが、Docker 1.13ではそのswarm関連の多くの改善が含まれています。 特に注目すべきはswarmクラスタに複数のサービスをまとめてデプロイする docker stack コマンド群のExperimental指定が外れたことと、dock
docker swarm 1.12.xのmanager1台/worker1台構成でクラスタ手動フェールオーバ/フェールバックして再起動する手順 - Qiita
docker swarm 1.12.xのmanager1台/worker1台構成でクラスタ手動フェールオーバ/フェールバックして再起動する手順Dockerswarm はじめに 先日swarm manager1台/worker1台の構成で、おもむろにmanagerノードのOS再起動したらクラスタがぶっ壊れて悲しい思いをしたので、ちゃんとswarmクラスタのメンテナンス手順を調べました。 クラスタ運用する場合はスプリットブレインを避けるためにmanagerノードを3台以上立てるのが理想的ではありますが、開発環境などではそこまでリソースを割けないのでmanager1台運用にしてます。で、おもむろにmanagerを止めるとクラスタが壊れるので、安全にやるには一旦workerをmanagerに昇格してフェールオーバさせて、managerノードを再起動し、フェールバックさせるという手順を踏む必要があり
PowerShellで電源スリープ設定が有効かどうか確認する - Qiita
電源スリープ設定が有効かどうかを確認する処理をPowerShellで書いたので貼っておきます。 えーっと、すごい煩雑です。 解説はスクリプト内にコメントで書いておいたのだけど、電源関連の設定はWMI経由で root/CIMV2/power の Win32_PowerPlanか ら電源プランの情報を取得し、 Win32_PowerSettingDataIndex から設定値の情報を取得します。 「次の時間が経過後スリープする」と「復帰時のパスワードを必要とする」の設定項目の InstanceID を決め打ちで指定している箇所があるのだけど、検証に使った複数のPCで同じ値になってたので、個体差はなさそうなんだけど、すべての端末やWindowsバージョンで同じなのかどうかは不明。レジストリキーっぽい香りがしてあんまり綺麗ではない。 function SubCheck-PowerSleep($sl
PowerShellで例外をキャッチしてエラーメッセージをイベントログに出力する - Qiita
PowerShellで例外をキャッチしてエラーメッセージをイベントログに出力しておくと、なんかあとあとデバッグが捗る。 PowerShellで汎用的に例外をキャッチするには、なんか処理のあとに trap[Exception] でキャッチすれば、なんでも拾える。なんか処理の部分を特にtryとかで囲う必要はないです。 このとき $error[0].exception にエラーメッセージが入ってるので、これをイベンログに出力しておけばOK。イベントログを書くのは Write-EventLog で書く。 # なんか処理 ... # 例外をイベントログに出力 trap [Exception] { Write-EventLog -LogName Application -Source MyApp -EventId 1 -EntryType Error -Message $error[0].except
PowerShellでWindowsPCの端末情報(OSバージョン/モデル型番/シリアル番号など)を取得する - Qiita
WindowsPC端末の情報(OSバージョン/モデル型番/シリアル番号など)を取得する処理をPowerShellで書いたので貼っておく。 情報源は WMI経由で取得できる Win32_OperatingSystem/Win32_ComputerSystem/Win32_BIOS あたり。 他にも足りないものあるかもだけど、とりあえずPC端末管理目的ならこれぐらい取っておけば十分かなと。 function Check-SystemInfo{ $systemInfo = @{} # Date # チェック実行日時 $systemInfo["CheckDateTime"] = Get-Date -Format "yyyyMMdd_HHmmss" # Environment # ホスト名 $systemInfo["EnvComputername"] = $env:computername # ユー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
