はてなブックマーク

※ 2020-12-22 追記あり はじめに この記事は GLOBIS Advent Calendar 2020 - Qiita 17日目の記事です。 GLOBIS SRE チームでは2020年初頭より、 Kubernetes (Amazon EKS) を用いたインフラ環境の全面的な刷新に取り組んでいます。この新たな環境では Infrastructure as Code で環境の9割はコード化するという目標を立てており、 Terraform を積極的に活用しています。 この記事では、そんな弊チームでの Terraform の使い方についてまとめていきます。書き始めたら書きたいことが湯水のように湧いてきてしまったので、FAQ形式でまとめてみました。気になるところを拾い読みしてみてください。 Terraform 全般 Q. Terraform で何を管理していますか AWS がメインの環境なの

この記事は GLOBIS Advent Calendar 2019 - Qiita の9日目です。 7月に GLOBIS へ SRE として参画してから、集中的に取り組んできたことの1つである「AWSマルチアカウントの構成や運用効率化」に関して書いていきます。 AWS マルチアカウント構成について GLOBIS では AWS アカウントを環境ごとに分ける構成を取っています。各サービスにつき開発、ステージング、本番環境という形で 3 アカウントを設けており、現在その総数は 20 に届こうかというところです。私が参画し始めた後にもアカウントは増えています。 マルチアカウント構成はポピュラーな AWS アカウントの使い方だとは思いますが、 GLOBIS の場合以下のメリットを感じています。 GLOBIS はサービスごとに開発チームが分かれており、各チームへ的確に分割された AWS IAM 権限を

表題の雑スクリプトを書いたので誰か欲しい人いるかなという感じで書いておきます。 背景 Evernote はノートのエクスポート形式が HTML か、独自の XML フォーマットだけであり、プレーンテキストは選べません。 また複数ノートを一括でエクスポートした場合、全ノートが1つの XML に結合されてエクスポートされます。 非常に扱いづらいのでプレーンテキストに変換することにしました。 一応先人の知恵もあるにはありました。以下は PHP での実装です。 panicsteve/enex-dump: PHP script that accepts an Evernote export (ENEX) file and produces a folder of plain text documents. しかし XML ファイルをまるごとメモリに載せてから処理する形式になっているため、 1000

sudo 実行時、環境変数は変身ユーザーのもので基本的に上書きされると認識しているのだが、実際どう上書きされているのかとか、実行ユーザー側のものを引き継いで使いたい場合はどうしたらいいのかとか、よくわかってないので少し調べたメモ。 なお、以下では sudo で他のユーザーに成り替わることを「変身」と呼称する。日本語版のMan pageでも使われている用語であるため。また確認はCentOS 7で行なっている。 デフォルトの挙動 環境変数の扱いは基本的には /etc/sudoers で管理されている。デフォルトでは漠然と「変身ユーザーの環境変数が適用される」と考えていたが、具体的には env_reset が有効になっている。 env_reset これを有効にしていると、変身後に「最小限の環境」が採用される。 最小限の環境とは、/etc/environment で初期化され、TERM, PATH

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Amazon Echo Dotを買ったので、早速Skillを自分で作るなどしてみたのだが、そのとき調べたことを書き記しておく。だいたい入門としてはこれぐらいの内容があれば足りるはず。 Alexaの開発についてはわりと資料が充実していて、公式のドキュメントもすでに日本語になっているし、ビデオを交えたトレーニング資料も存在している（現時点ではまだ途中までの公開）。 Alexa Skills Kitによるスキルの作成 | ASK Alexa | Alexaスキル開発トレーニング また国内販売開始からは日が浅いものの、それ以前にすでに開発を試し

influxDBとGrafanaで様々なメトリクスグラフを作っていて、基本的には気に入ってはいるのですが、ちょいちょい痒いところに手が届かないのでまとめておきます。 influxDBとGrafanaの基本については こっち 参照で。なお用途としてはAPI叩いた結果を格納したり、サーバーからメトリクスを上げさせて格納したりということをしています。 RP, CQによるダウンサイズとGrafanaの付き合い方 InfluxData | Documentation | Downsampling and Data Retention influxDBにはContinuous QueriesとRetention Policiesという機能があり、これを利用したデータの定期的なダウンサンプリングが公式でも推奨されている。 Continuous Queries (CQ) CQは名前の通り、一定間隔で継続的

あまりまだメジャーではないみたいですが、HashiCorpが機密情報管理用のツールとしてVaultを出しています。代替になるツールもあまり思い浮かばないし、物は試しと使ってみました。 Vaultでできること概要 機密情報等をKey,Value形式で書き込むと暗号化して保存してくれる。 Secret Backendsという機能で、MySQL、PostgreSQL、AWS、LDAP等と連携し、Vaultを通じてユーザー情報の追加、変更、削除等を行える。このときLease（期限）を設定し、一定期間後にアカウントを自動削除したり、パスワードをRevokeさせることができる。 デフォルトの状態ではデータはすべて暗号化（Sealed）されており、Vault自身も復号する方法を知らない。復号には分散鍵による認証が必要になる。 Vaultへのアクセス方法はCLIかREST API。 Vaultへアクセスす

※追記アリ： サービス仕様の変更により、すでにこの話は古くなっています。 長年独自ドメインの下でプロフィールサイトをVPSに置いていたのですけど、いまどき静的サイトを返すのに自力でnginx動かす必要もなさそうだし、VPSの料金もかかってるし、AWSでなんとかしようと考えました。 さらに、せっかくだからサーバーレスアーキテクチャーっぽくしようと思い、「サイトにアクセスが来たとき、Lambdaで自ブログのRSSを取得して、ページに最新記事のリンクを埋め込む動的な構成にしてみよう」と考え、AWSでちょっと動的なページを作ろうとしたわけなのですが、当初想定していた以上にいろいろ大変だった、という記録です。 ぼくの考えた設計（第1形態） はじめはわりと簡単にできるやろ〜と気楽に考えてました。こんな感じで。 API GatewayからLambdaにつなげ、LambdaでRSSを読み込み、動的にページ

背景 可視化ツールとしてはElasticsearchを常に使っていたのですが、いわゆるサーバーのメトリクスデータのような数値データを記録するのであれば、influxDBというのもあるということでお試し。 influxDB + Grafanaの概要 influxDBは時系列DB (Time series database) と呼ばれるソフトウェアに分類される。時系列DBはその名の通り、時間を追うに従って変化するようなデータを格納する機構を備えたDBで、英語版Wikipediaだと記事ページがあるが、これによればRRDToolも時系列DBとされるよう。 RRDToolとの比較も考えつつ、influxDBの特徴を上げると以下のような点。 データ登録はREST APIを通じてjsonで可能。 デフォルトで認証機構を備えている。 クエリはSQLに準じた文法を使用することが可能。 Web UIを備えて

AWS CLI自体が今月始めたばかりぐらいなのだが、とりあえず手始めにということで、Lambda関数を作成してみた。昨年リリースされたLambdaのスケジュール実行を利用し、EC2インスタンスの自動起動／停止を題材としている。 IAMロールの作成 AWSにおけるリソースアクセスの権限制御にはIAMが使われるわけだが、リソース間のアクセスには「ユーザー」や「グループ」ではなく「ロール」が使われる。順序としては、Lambdaが引き受けることのできるロールを作成し、そのロールに対して、対象EC2の停止／起動が可能なポリシーを割り当てる、という2段階になる。 まずロール作成のため、設定を書いたjsonファイルを作成する。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole"

気づいたら足していく。 全体設定 LinuxであればHTTP_PROXY環境変数に設定する。不都合なければ.bashrcとかで設定してしまえばあとは楽。Windowsはインターネットオプションで設定する。

環境はCentOS6.x以上もしくはCoreOS。Docker Docsに記載されている内容を実践して、少し知見を付け加えたものです。 前提：Dockerコンテナのネットワーク構成 Dockerサービスを起動すると自動的にdocker0と呼ばれるbridgeが作成され、すべてのコンテナはこのブリッジに接続される。 $ ip a show docker0 3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 02:42:ba:8a:43:a5 brd ff:ff:ff:ff:ff:ff inet 172.17.42.1/16 scope global docker0 valid_lft forever preferred_lft foreve

基本的にAnsible側に制御を委ねることで冪等性の保持やエラーハンドリングが成されるので、やりたいtaskに対してまずはmoduleを探すべき（sedを使わずにlineinfileモジュールを使えないかとか）ではあるのだが、どうしてもmoduleで実現できない場合にシェルコマンド直書きになってしまう場合はある。 てかコマンド書いちゃうならAnsibleじゃなくてシェルスクリプトでいいじゃんって話でさ。 ※追記 2017-04-05 17:00 記事執筆時点から時を経た現在の自分の見解としては、shell, command両モジュールの活用には以下の面から否定的であり、なるべくコマンド実行は行わないべきと考えています。 冪等性の保証が困難になる。 Ansible Playbookは実現されるべきシステムの「状態」を示した「実行可能なドキュメント」という側面があるが、コマンドが記載されている

本記事は拙ブログ記事「暗号化とハッシュ化に関する基本的な事柄まとめ - the world as code」のリファイン版です。 暗号化とハッシュ化は違う。暗号化はデータの秘匿を目的としており、適切な鍵を用いることで復号が可能。ハッシュ化はデータの置換がそもそもの目的であり、ハッシュ関数により一定のフォーマットへ不可逆の変換を行う。 ただし、衝突耐性を持つことなどにより、セキュリティ用途に適する「暗号学的ハッシュ関数」というものもあるらしい。デジタル署名やメッセージ認証符号への使用を目的とされており、逆にチェックサム等に使用するには計算が「重い」。 アルゴリズム RSA 公開鍵暗号。素因数分解の計算難度を根拠としたもの。なおRSAは発明者の名前から取られたものであり、何かの略ではない。 SSHログイン時の鍵認証やSSL認証など、広く使われる。 秘密鍵生成コマンドとしてopenssl gen

昨年のJAWS DAYS（3/22）のハンズオンでAWSアカウントを作り、そこから1年間の無料期間でいろいろやったことを書き出す。正直言ってきちんと活用し切れなかったなぁという思いがあるので参考にならないかも。 最初にやること 気を付けるポイントとしては セキュリティ と 課金 かと。以下、だいたいがよく言われていることではある。 IAMユーザーを作成する IAMはAWSの権限管理のためのサービス。最初にAWSアカウントを作成したときに使った、メールアドレスをユーザー名とするユーザーはいわゆるrootユーザーにあたるので、AWSコンソールへのログインにはIAMで新たにユーザーを作成して使用するのが適切。またGoogle Authenticator等で他要素認証も設定しておく。 Trusted Adviserを設定する Trusted AdviserはAWSの使用状況がコスト、セキュリティ、

Ansible自分でやってみると書くの短時間で済むし、構成はシンプルで管理しやすいし、だいぶ好きになってきました。まだ開発用のVPS1台作るのに触っただけなので本格的に学べてはいないですが、導入部分とつまずきポイントをさっくりまとめときます。自分のplaybookは以下レポジトリ。 Ansibleの構成 やっていることは極めてシンプルで、サーバーの設定／構築等の処理を「モジュール」と呼ばれるリソースで定義し、指定したIPやホスト名の対象サーバーに対して、SSH経由で処理を流し込んでいくというだけ。ansibleコマンドを使ってコマンド1発だけを送ったりもできるけど、基本的にはモジュールを複数記載した playbook と呼ばれるyamlファイルを用意して、ホスト情報も インベントリファイル にリストアップしていくことになる。playbookを使用したデプロイにはansible-playbo

Docker、コンテナやらイメージやらという用語が混同してしまったり、データや構成がどこで保持されてどこで破棄されるのかといったライフサイクルが理解できていなかったのでまとめた。 イメージとコンテナ イメージはコンテナのもととなるデータ。Docker Hub などのコンテナレジストリに公開されているイメージからダウンロードして使ったりDockerfileからbuildしたりする。一方のコンテナは、実際にイメージから起動したマシンを指す。当然ながら1つのイメージから複数のコンテナが起動できる。 Docker Hubから任意のイメージを取得（pull）し、内部構成をカスタマイズして保存 （run && commit もしくは Dockerfile を書いて build）、そのイメージからコンテナを起動（run）して利用、要らなくなったらコンテナを停止（stop）して破棄（rm）というのが一様の

Dockerでイメージを永続化するには通常commitを使うが、この他に状態保存に関するコマンドとしてsaveとexportがある。いずれもコンテナをtarにまとめて吐き出すような挙動をするが、それぞれ動作が異なる。 Dockerコンテナの内部構成 その前にDockerコンテナの内部構成に関して把握する必要があるが、以下のページが大変詳しくて参考になった。 Dockerイメージの差分管理についてまとめてみた | TANKSUZUKI.COM Dockerコンテナは構成を「差分」という形で管理していく。Dockerfile内でRUNやADDを行うと、それは都度差分として記録されるので、闇雲にRUNを重ねるとコンテナがぶくぶくと膨れていく。ちなみに差分（レイヤー）数の上限は127だそうだ。 そういったコンテナの構成を踏まえてのこれらのコマンドの差異を見る。 save 上記のレイヤーやタグといっ

Gitでリモートレポジトリとやり取りする際のプロトコルにはhttp(s), git, sshの3(4)種類があって、特にGitHubとのやり取りにおいては各プロトコルによって出来ること／出来ないことの差がある。 http(s) GitHubの推奨はhttps。 httpに関しては記載がないが、一応使える（が、あえて使う意味もないと思う）。 認証はGitHubのユーザー名、パスワードによる。 GitHubで2段階認証を設定している場合は、 パスワードの代わりにアクセストークンが必要になる。 git 高速らしい。 GitHubでは昔は言及があったと思うが、現状は言及がない。が、使える。 認証機構を持たないため、gitプロトコルでgit cloneした場合はread-onlyになる。 ssh セキュア。GitHubの場合は鍵認証を行いたいときに使う。 というかだいたいのユーザーは鍵認証していると

やりたいこと 脆弱性情報をTwitterで知ったりJPCERTにわざわざ見に行ったりとか面倒なので、スクリプトで自動収集してRedmineとかにチケット登録までやってもらえれば楽だと思う。メールでチケット登録はメンバーに報知されるので、それ見て個々の対応要否を確認、担当者や作業範囲の割り振りをRedmine上で行う。まだ検討していない脆弱性情報はまるわかり。一元管理最高。 メリット 楽。確実。 対応のログも追うことができる。 チケット番号を共有すればメンバーへの報知も楽。 デメリット チケットが溢れ過ぎやしないか？ なにもかも自動にすると逆に気にしなくなるフラグ。 無関係なプロダクトの情報までは必要ない ⇒収集時にキーワードで弾けばいい そもそも脆弱性情報とは 各ベンダーが配信していたり、ITmediaのようなニュースサイトが取り上げていたり色々あるが、確実な情報ソースとして、OSS、商用

筆者はsystemdどころかinit自体よくわからない状態からスタートしています。 従来のSysVinitやUpstart（RHEL6における実装）に代わるサービス管理のアーキテクチャー。 Fedora15で採用後、2014年リリースのRHEL7（CentOS7）でも正式採用、事実上の標準となりつつある。 従来 /sbin/initが/etc/inittabに記載された各ランレベルごとの設定に従ってすべてのプロセスをrcスクリプトによって起動していく。 rcスクリプトの実体は/etc/init.d内のシェルスクリプトのシンボリックリンク。/etc/init.dはserviceコマンドでの起動終了等でも操作しているもの（実際は直接スクリプトを叩くのとserviceコマンドとでは差異がある模様で、直接だとカレントの環境を使ってしまうので望まぬっ結果となる可能性があるらしい）。 この他にも/sb