Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 闇が深いとは このくらいを指すものとします。 AMIの出所がわからない EC2インスタンスのAMI IDが、自前AMIになってる Linuxディストリはわかるが、起点にしたバージョンはわからない AMIがどうやってできたのかわからない sudo vi /etc/hoge.conf してるっぽい sudo yum install -y hoge してるっぽい wget https://~~~~/hoge.tar.gz から make install してるっぽい AMI更新手順がわからない 変更したい人々と、変更できる人々が違っている 実
はじめに 受託開発において、比較的小規模なフルスクラッチのWebシステムを開発する場合、インフラ関連の工数の中でWeb／アプリケーション（AP）サーバの構築に対する工数が比較的多くなってきます。 また、複数のプロジェクトにおいて、同じような作業を繰り返し実施する必要があり、手作業で構築を実施する場合、繰り返し実施する中で手順書が修正され続け、いわゆる「秘伝のタレ」となり再現性が失われるケースが多々あります。 本稿では、開発環境及び本番／ステージング環境において、Web／APサーバを構築する際に「再現性があり」「繰り返し利用が可能で」「短時間で構築が可能な」方法として、Ansible、Vagrant、Packerを用いた実践方法をご紹介します。 Ansible、Vagrant、Packerの役割 Ansible、Vagrant、Packerは既に多くの事例でも採用されているため、ご存知の方も
研究開発部の染谷 ( @ayemos_y ) です。好きな ImageNet のラベル(Synset)は "Eccentric, eccentric person, flake, oddball, geek" です。 クックパッドの研究開発部は2016年7月に発足し、現在はアルバイトを含め13名の体制となっています。その中で、こちらの記事でも紹介されている料理／非料理判別モデルを開発するなど、機械学習／ディープラーニング分野に特に力を入れて取り組んでいます。 最近は、モデルを開発し改善する手法などについて多くの情報にアクセス出来るようになり、このような技術をプロダクトに応用していきたいという気持ちが高まっている現場が多いかと思います。しかし一方で、分析の為のデータへのアクセスや画像認識モデルの実装や実験を行うためのGPU環境の整備など、現場の都合に対応するコストによって開発の勢いが鈍化して
今回はGCPでの検証を行った際の進め方について説明していきます。インフラを作り込みすぎずに検証したことで、早めに想定外のボトルネックに気
この記事は Recruit Engineers Advent Calendar 2016 の22日目の記事です。 昨日はmookjpさんのLet It Crashとは何かでした！ゴイスー！ 本日はサーバサイドエンジニアとして従事している私がAWSでインフラ構築をした記事となります。 この記事を書く1週間程前はそろそろ記事の下書きをしておくかー。 と、やる気に満ち溢れていたのですが、悲しきかな・・・PS4 proが届き当時の気持ちはどこかに置いてきてしまったようで、急いで先程記事を書き終えました。 はじめに 日々やらねばいけないことが満ち溢れている中、運用やサーバトラブルに対して時間は割きたくないものです。例えば、EC2の突然死やメンテナンスです。 限られた時間の中でより効率的に時間を使いたいという欲求を皆様お持ちではないでしょうか。 そこで楽をしようと思い立ち、本エントリーの構成にしたので
http://hatena.connpass.com/event/37799/
はじめまして。4月にアクトキャットにjoinしたwata727です。主にサーバサイドの開発やAWSをはじめとしたインフラ周りを担当しています。よろしくお願いします。 今回は直近行ったSideCIインフラのAWS完全移行に、TerraformやPackerを採用した話について書いてみます。 SideCIのインフラ構成 SideCIではサーバの役割をフロント側でユーザの操作やリクエストを受け付けるweb群と、Rubocopなどのツールを実行するnode群に分けています。役割を分離することにより、関心事を分けることができ、必要に応じてスケールアウトやスケールアップがしやすくなるメリットがあります。 もともとはAWSとGCPのハイブリットクラウド構成をとっていたのですが、さまざまな問題があり、今回の再構築の段階でAWS側に完全に寄せる形になりました。 Infrastructure as Codeの
はじめに 藤本です。 昨日、Packerのバージョン0.9がリリースされました。Chef ProvisionerのWindows対応や、OVA形式でのAWSへのインポートなどいくつかの機能が追加されました。今回はその中でもAnsible Provisionerについてご紹介します。 リリースノートはこちら 概要 Packerには今までAnsibleのProvisionerとして、Ansible Local Provisionerがありました。Ansible Local ProvisionerはPlaybookをビルドOSに送信して、ローカルでAnsibleコマンドを実行するというものでした。事前にAnsibleをインストールしていなくてはならないことでAWSなどで標準OS AMIを利用する場合、Shell ProvisionerでゴニョゴニョとAnsible外で設定を入れえなくてはいけなか
前回の記事ではDockerとECSを使ったAWS上でのInfrastructure as codeについて言及しましたが、サーバリソースの構成管理についてはAWSのマネージメントコンソールから手動で行わないといけなかったり、コンテナを用いたアプリケーション構成を強制され、従来の単純なインスタンス構成ができないという問題点がありました。前回の記事はこちら。 後者については、今後コンテナを活用したインフラ構成が普通になっていくことで許容されていくかもしれませんが、普通にインスタンスを立ててインフラを構築している方にとってはInfrastructure as codeをやりたいためにコンテナを前提としたサーバ構成に変更しなくてはいけないなんて、正直気が進まないと思います。 そこで本記事では、今インフラ界隈で非常に強い影響力を持っているHashicorpのプロダクト、PackerとTerrafor
HashiCorp Advent Calendar、15日目の記事です。 今回のテーマは Packer です。 Packer pluginとは Packerの特徴の一つに、イメージの構築のための様々なフェーズをレイヤ分けして、それぞれでプラグインという形で分離しているところがあります。 Builder Plugins (AWS, OpenStack, GCE, QEMUなどのプラットフォーム層) Provisioner Plugins (Shell, Upload, Chef/Puppet/Ansible...) Post-Processor Plugins (DockerやVagrant Cloud周りの操作など、イメージ作成後の挙動) プラグイン機構を採用しているので、環境ごとに自分でプラグインを作成して拡張することも可能となっています。 筆者は以前、DHCPなしのOpenStack向
以前試した Packer 用のテンプレート misheska/basebox-packer が Box-Cutter に移動してしまい、若干使い方も変わったようなので試してみました。 packer 自体のインストールは割愛。 Box-Cutter https://github.com/box-cutter 上記の Organization アカウントの下にディストリビューション毎にプロジェクトが作成されているので、必要なものを clone します。 ここでは CentOS 用のプロジェクトを clone しました。 % git clone https://github.com/box-cutter/centos-vm.git 作成したいバージョンの json ファイルを編集します。 ファイル名で大体どれを弄ればいいかは分かるはず。 % cd centos-vm % vim centos65
エンジニアの内田 @spesnova です。 2015年8月5日に、@deeeet さんと一緒に Wantedly のオフィスにて Hashicorp Product Meetup と称して、 Hashicorp プロダクトに関する知見、悩み、展望 etc をフランクに共有する会を開きました。 参加者全員がゆるくざっくばらんに話せる場を作りたいと思って招待制のイベントにしました。 参加者の方は @deeeet さんと自分の知り合いの方から、Hashicorpプロダクトを既に利用していたり、導入予定の方々にお声をかけせて頂き、その方々がまた数名招待するという形にしました。 「行きたかった…」というツイートもチラホラありました、、参加できなかった方ごめんなさい。。 どんな内容だったのかをtogetterと以下に簡単にまとめておきます: http://togetter.com/li/856947
Packer is a tool that allows users to create machine images for multiple platforms from a single source configuration. It supports cloud providers like AWS, Azure, GCP and OpenStack. The document discusses using Packer to create optimized OS images with tools like cloud-init for fast provisioning and deployment of applications during scale-out operations. It also describes integrating Packer with
一部のサブシステムの構築で、プロビジョニングツールを捨ててみた。じゃあどうするのかというとシェルスクリプトでやる。今回はこのやりかたが一番楽できるような気がしたので試している。 具体的にはPackerからシェルスクリプトとServerspecを実行してAMIを煮込む。おいしくできあがったらそいつから構築。もしミドルウェアより下の層のコンフィグ類に変更があったらまた煮込む。構築する。新しい方に切り替える。つまり”捨てるインフラ”にする。 プラットフォームはAWS。 (追記)ちなみにchefなどのプロビジョニングツールがめんどくさいからシェルスクリプトにしたというよりは、捨てる前提のサーバだからシェルスクリプトでの構築も選択肢として出てきたということです。ただ自分個人の嗜好としてchefはもう飽きたというのも事実です。なお、オンプレだと同じサーバで継続してプロビジョニングすることになるのでch
Packer が Atlas の UI を通して、リモートでも使えるようになる、という HashiCorp ブログの投稿がありました。これまではコマンドラインでの作業が必要でしたが、今後はそれが不要。しかも、ビルド時の情報やアーティファクトを共有できるようになりました、という内容です。最後で、今後は GitHub との連携や、 Packer と Terraform との自動連係について触れられています。 というわけで、例によって参考訳です。 原文： Packer in Atlas: Automate the Building and Managing of Vagrant Boxes and Machine Images https://hashicorp.com/blog/atlas-packer-vagrant.html ※一応書いておきますと、本blogでの投稿は私個人の意志によるも
1. Masahito Zembutsu @zembutsu Technology Evangelist; Creationline , Inc. Shinjuku Tokyo, Apr 10 2015 #hbstudy 66th Meetup 今日から始めるDigitalOcean All About DigitalOcean – Practical Introduction 2. 今日から始める DigitalOcean 2 / 99 今日の内容 “できる☆DigitalOcean” • 入門：DigitalOceanとは？ これはクラウドですか？ 登場背景、機能概要、特長、料金体系、契約方法、支払い、SLA • 実践：DigitalOceanの機能・操作方法 使う前に知っておきたかった機能 - Dropletやテンプレート、バックアップ、プライベート接続、DNS機能 • 応用：クラウ
HashiCorpとは？ 「HashiCorp」という名前を知らなくても、Vagrantというツールの名前なら聞いたことがある、もしくはすでにお使いの方もいらっしゃるのではないでしょうか。Vagrantは仮想化された開発環境を簡単に立ちあげられるため、開発者サイドにとってはおなじみのツールです。このVagrantを開発したMitchell Hashimoto氏が創業した会社の名前がHashiCorpです。 HashiCorpが提供するツールは、開発者向けのものだけでなく、運用担当者向けのものもあります。連載初回の今回は、HashiCorpとは何であり、どのようなツールを、どのような考えで提供しているのかを紹介します。 HashiCorpの沿革 きっかけはVagrantの開発がスタート地点でした。Mitchell Hashimoto氏が2010年にVagrantバージョン0.1をリリースした
最近、仕事やら趣味やらで AWS / OpenStack / GCE その他のいわゆるIaaSなプラットフォームを調査したり、いじったり、そのAPIをいじったりする機会が多かった。 この辺の運用を考えていて試したこと、ぶつかったことなどをまとめたい。 実際やったこととしては、特定のプラットフォームに依存している訳ではないが、たいていの人はAWSのアレね、みたいなイメージを持った方が読み進めやすいんじゃないかと思う。 ゴールデンイメージを雑に走らせること この手のIaaSの基本であるが、サーバーはインスタンスと呼ばれ、イメージを指定して起動する。ec2 aws run-instanceとかnova bootとかその類いである。 イメージからの起動のためには雑には大きく2要素があって、一つはイメージ自体の構築、もう一つは起動直後のそれぞれのインスタンスの特性に合わせた初期化処理のフェーズである
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く