Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
2016 - 12 - 11 最近のTerraformのディレクトリ構成こうなった Terraform DevOps Terraformの運用を初めてなんだかんだで1年半くらいたったんですが、プロジェクトによって環境も運用も違うので開発環境や本番環境の構成をどのように管理しているかというのは結構バラける気がしてます。1年半経過して行き着いた形を雑にシェアするだけのエントリです。 前提 環境の系統は dev(develop)/ stg (staging)/ shd (shared)/prd(production の4系統がある ドメイン は本番用の ドメイン と開発用の ドメイン で完全に分けている 全てのリソースをTerraformで管理してはいない。これからもするつもりはない。 以前書いたエントリ で、運用で状態が変わる性質のあるものには不向きだったり(状態変化を無視設定はあるが)、独自
この記事はLint Advent Calendar 2016の6日目の記事です。 本記事では、インフラもLintしませんかという提案と、そのために今作っているツールの紹介をします。 TL;DR Infrastructure as Codeによってソフトウェア開発の良いプラクティスが活用できるようになった つまり、Lintの知見もインフラに活用できるはず 試しにTerraformのテンプレートをLintするTFLintを作りました Infrastructure as Codeがもたらした恩恵 Infrastructure as Codeは既に広く知られるようになった考え方だと思います。ここまで普及したのは、AWSなどのIaaSの存在ももちろんあったと思いますが、ソフトウェア開発におけるGitによるバージョン管理や、PR駆動開発などの良いプラクティスが広く開発者に受け入れられていたことが背景に
インフラチームエンジニアの藤田 (@dtan4) です。Terraform でインフラをコードで管理するようになって1年が経ちました。 Wantedly のインフラは AWS + DNSimple 上で稼働していますが、そのリソースの殆どをおよそ1年前から Terraform のコードで管理しています。もちろん1年前の時点で既存のリソースは数多くあったわけですが、それらも Terraform のコードに落としこむため Terraforming という変換ツールを作りました。現在ではインフラ変更の際に GitHub 上で Pull Request によるレビュー + CI 上で自動適用を行う体制が整っております。 以前 Wantedly Advent Calendar '15 で Wantedly での Terraform 運用事情を一通り紹介しましたが (Terraform と CI で実
Infrastructure as Code という言葉が現れてから少なくとも8年ほど経過しており、この言葉もすっかり定着したように見えるが、Martin Fowler 氏が最近自身のブログで Infrastructure as Code について触れており 、また、氏の同僚である Kief Morris 氏が O'Reilly Media から Infrastructure as Code という本を出す(現在 Early Relase 版や Free Chapters が入手できる)ようなので、このタイミングで改めて Infrastructure as Code について、その歴史を振り返るとともに、現在の状況について整理してみようと思い、このエントリを書くことにした。 内容的には、以前書いた インフラ系技術の流れ と若干重複してる部分もある。 そういえば日本でも最近、サーバ/インフラ
この文章は、サーバサイドのウェブアプリケーション開発において、社内実績の少ない新しい言語を採用したときにインフラ面で考慮したことを社内向けにまとめたものです。 はてなでは、長らくPerlでウェブアプリケーション開発を続けてきた一方、ここ数年で社内でScalaまたはGoの採用事例も増えてきました。 今後開発が始まるプロダクトにおいても、Perl、Scala、Goもしくは他の言語を採用するかどうかを開発開始時に選ぶことになるでしょう。 新言語を採用するときに、考慮すべきことの一つとして、「インフラ」への影響があります。 新言語に関する雑談をしていると、ウェブアプリケーションエンジニアに「インフラ」への影響について聞かれます。 もしくは、ウェブオペレーションエンジニアから考慮するポイントを伝えることもあります。 ScalaやGo以外に、Node.jsやサーバサイドSwiftはどうかというのも雑談
dots. Conference Spring 2016 ゲーム開発の裏側 http://eventdots.jp/event/580344
私はここ1週間ほど、同僚の David の一言で Infrastructure as Code について頭が大混乱状態でした。 それは次の一言です。 Chef や Puppet は大体の部分は Infrastructure as Code じゃないよね。ARM (Azure Resource Manager) はそうだけど。 ただ、Chef-Provisioning は Infrastructure as Code だよね。 もう頭が大混乱です。なんとなく言わんとしていることはわかりますが、私は今まで Chef とか、Puppet とか、Ansible とかで やっているようなことが、Infrastructure as Code と思い込んでいましたが、何か間違っていたのでしょうか?そういえば、 Chef はConfiguration Management Toolと紹介されていたなとか頭
AWS Partner Network (APN) Blog Terraform: Beyond the Basics with AWS Editor’s note: This post was updated in March 2018. By Josh Campbell and Brandon Chavis, Partner Solutions Architects at AWS Terraform by HashiCorp, an AWS Partner and member of the AWS DevOps Competency, is an infrastructure as code (IaC) tool similar to AWS CloudFormation that allows you to create, update, and version your Amaz
今年からAWS(Amazon Web Services)クラウドコンサルタントとして、中小規模のAWSデプロイの相談を受けています。その多くは典型的なWebアプリケーションです。ここで、ぜひ避けたい5つのよくある間違いを紹介します。 インフラストラクチャを手動で管理する。 Auto Scaling グループを使わない。 CloudWatchのメトリクスを分析しない。 Trusted Advisorを無視する。 仮想マシンを活用しない。 典型的なWebアプリケーションにおける間違いを防ぎたい人は、次に進んでください。 典型的なWebアプリケーション 典型的なWebアプリケーションは最低限次の要素で構成されているものを指します。 ロードバランサ スケーラブルなWebバックエンド データベース そしてこのアプリケーションは、次の図のような仕組みを持っています。 注釈:(左から)DNS、CDN、静
Wantedly Advent Calendar 2015 __18__日目です。 インフラチームインターンの @dtan4 です。 Wantedly では Terraform を用いたインフラのコード化 (Infrastructure as Code) を全面的に取り入れています。インフラリソースの追加や修正は、コードを書くこと・CI 上での自動適用によって行われています。 この記事では、今年5月から半年以上の間 Terraform を運用してきた中での なぜ Terraform でインフラをコード化しようとしたのか どのように Terraform を運用しているのか Terraform 運用にあたって注意すべき点 既存リソースから Terraform コードを生成する Terraforming について ということを紹介したいと思います。 Terraform とは Terraform
この記事ははてなデベロッパーアドベントカレンダーを始めます - Hatena Developer Blogの17日目の記事です.昨日は id:yashigani_w の Promiseを学ぶためにSwiftでPromiseを実装してみた話 - yashigani?.days でした. こんにちは、はてなの id:wtatsuru です。はてなのインフラ全般をみています。 はてなでは、しばしば新サービスを構築する機会があります。正式サービスもあれば、はてラボ のような実験的サービス、内部の Microserviceの一部になっているものなど多種多様なものがあります。新規サービスのインフラを構築する際は、最小構成でありつつ後のスケールやメンテナンスを考えた仕組みを作っていくことになります。この記事では、2015年12月現在のはてなでの標準的な構成を紹介していきます。 新サービスの最小構成 こち
工夫したこと リソースの分離をファイル単位で行い、使い回しができるように配慮した Backlogチーム以外でも利用できるようになるべくAWSリソース単位でファイルを分割しておき組み合わせるだけでリソースが構成できるように配慮しました。 ファイル構成例を記載していますがterraform applyを実行したときに全ファイル読み込んですべてのリソースを作成してくれます。 depends_on設定をしておくと各リソースの依存関係を制御できすべてのリソースをいっきに作成することが可能です。 . ├── config.tf ├── terraform.tfstate ├── terraform.tfstate.backup ├── user_data │ └── api.tpl ├── variables.tf ├── vpc-db-instance.tf ├── vpc-db-subnet-
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く