deployに関するshin1x1のブックマーク (16)
-
shin1x1 2016/03/02
-
Dockerとchrootを組み合わせたシンプルなコンテナデプロイツール - ゆううきブログ
この記事ははてなエンジニアアドベントカレンダー2015の1日目です。今回は、既存の運用フローに乗せやすいDockerイメージへのchrootによるデプロイの考え方と自作のコンセプトツール droot を紹介します。 github.com 背景 Docker 本番導入の課題 Docker 導入の目的 Docker + chroot のアイデア droot: Dockerイメージにchrootするコンテナツール droot の使い方 droot push: Dockerイメージをtar ball化しS3にpushする droot pull: S3にpushしたイメージをダウンロードし展開する droot run: 展開先のディレクトリにchrootする droot の実装 droot push/pull の実装 droot run の実装 あわせて読みたい あとがき 背景 Dockerがリリー
-
#10 Consulと連携するpull型デプロイツール stretcher - KAYAC Engineers' Blog
tech.kayac.com Advent Calendar 2014 10日目担当の @fujiwara です。 最近書いている stretcher というデプロイツールの紹介をしたいと思います。 長いので3行で push型デプロイはホスト台数が増減しやすい環境に適さない 各種問題を解決するpull型デプロイツールを書いた Consul と連携するよ 中央ホスト配布(push)型デプロイの問題点 カヤックの自社サービスでは久しく Archer というツールを利用し、中央ホストから各デプロイ対象ホストに rsync でファイルを配布する形のデプロイを行っていました。ここではこれを push 型と呼びます。 push型のデプロイは、ホスト台数が頻繁に増減する環境で以下のような問題があります。 新しくホストが起動してきた場合に、中央ホストからデプロイを行ったあとでないと (古い状態で起動してい
-
-
GunosyのMicroServicesとOpsWorks / よくわかる AWS OpsWorks
2015/03/26 よくわかるAWS OpsWorks
-
-
-
AWS News Blog
Top Announcements of the AWS Summit in New York, 2023 It’s probably no surprise that generative artificial intelligence and machine learning were the stars of the show, but there were several other bright lights from the day-long cloud conference. New Seventh-Generation General Purpose Amazon EC2 Instances (M7i-Flex and M7i) Today we are launching Amazon Elastic Compute Cloud (Amazon EC2) M7i-Flex
-
Deploy Your Website Using Laravel and Git — SitePoint
September 6, 2014Deploy Your Website Using Laravel and Git Key Takeaways Laravel and Git can be used together to efficiently deploy websites, with Git handling file changes and Laravel automating repetitive tasks. This allows for a streamlined and controlled deployment process that can be customized to individual needs. The deployment process involves setting up a central repository, creating loca
-
Bocchi Driven Development
こもりはひとりで仕事することが比較的多いんですね（BDD）。で、最近はこんな感じのシステム構成でやることが多いのでそれを紹介してみましょうかね。 Gitで管理しつつ半自動化 ボッチでの作業であってもなくても、仕事に関わるものは基本Gitの管理下に置くようにしています（ローカル）。何かやる時は自分でサーバから用意することが多いのですが、テスト用であっても本番用であってもそのサーバの中でGitを動かすことはありません。 BeanstalkなどのGitのリモートリポジトリにローカルからPushした時、自動的に何かしらのプロトコルでリモートのサーバにデータが転送（デプロイ）されるようにしています。たとえばこのブログの例でいくと、テーマの編集をしてそれを反映させるためにリモートのGitリポジトリにPush。Pushされたら変更分だけがこのブログが動いてるDigitalOceanのサーバに転送されます
-
Herokuの中の人が書いたWebアプリケーション構築の方法論「The Twelve-Factor App」の日本語訳 - orangain flavor
2016-01-14追記: 日本語版は随分前に本家にマージされたので、記事中のURLも変更しました。 The Twelve-Factor App はHerokuの中の人 Adam Wiggins氏によって書かれた、モダンでスケーラブルかつ継続的デプロイ可能なWebアプリケーションを構築するための方法論です。 2011年に書かれた記事ですが、とても有用な内容だったので勉強を兼ねて日本語に訳してみました。 The Twelve-Factor App（日本語訳） 目次は以下のとおりです。 コードベース バージョン管理されている1つのコードベースと複数のデプロイ 依存関係 依存関係を明示的に宣言し分離する 設定 設定を環境変数に格納する バックエンドサービス バックエンドサービスをアタッチされたリソースとして扱う ビルド、リリース、実行 ビルド、リリース、実行の3つのステージを厳密に分離する プロ
-
-
Tomcat7 でゼロダウンタイムデプロイ - mallowlabsの備忘録
「Web アプリのバージョンアップ時に Tomcat を再起動してもいいのは小学生までだよねー」 ということで、Tomcat でダウンタイム無しで Web アプリのバージョンアップをする方法についてまとめてみる。 Parallel Deployment Tomcat 7 から Parallel Deployment という機能が追加され、同一 Web アプリの複数バージョンを同時にデプロイができるようになった。 war のファイル名を somewebapp##001.war 等にしておくことで、 - $CATALINA_BASE/ - webapps/ - somewebapp##001.war - somewebapp##002.warのように配備をすると、 http://localhost:8080/somewebapp/ でアクセスした場合に、セッションが継続している場合には古い方(
-
CakePHP2アプリケーションをCapistranoでデプロイする
アプリケーションのデプロイを自動化すべきなのは言うまでもないことです。 一応手動でデプロイを行う場合の問題点について整理しておくと以下になります。 プロジェクトの期間中そして運用に入ってからも何度も手でデプロイするということはとてつもなく多くの時間を手作業に費やすことになるデプロイ先の環境の数が多くなればなるほど作業の時間も増える手作業で作業すると間違えやすい。特に手順が複雑だったり環境が多かったりすると確率は飛躍的にあがるもしデプロイしたアプリケーションに問題があってすぐに戻さなければならない場合に多くの時間がかかる。場合によってはビジネス上の機会損失に繋がる本来は価値を生むフィーチャーを実装することに時間をかけたいはずが、こういうことをやっているとどんどん時間がなくなっていきます。また手作業のリスクや消費される時間を恐れてデプロイの回数を減らしてしまうのは、ビジネス側からみると納得いか
-
デプロイ自動化メモ - ku-sukeのブログ
組織の規模や、制作する対象の「手を入れ続ける期間」、そして最終的に世に出す時の細かな後処理の多さを勘案して、自動化について調べることにしました。 こういうものは、学習コストが初期段階発生して、後半で楽できるっていうかないとやってられない様なたぐいのものなのですが、そのへんの損益分岐点を超えたぜっていう感覚があったので大急ぎで調べてます。 サーバアプリ面 現状PHPをさわっているのですが、PHPのデプロイシステムってあんまり世に出ているもので定番っていうのがない気がします。 今のところ、ど新規のサービスということもありWAPが5台未満のサービスが多そうなので、SVNから落としてきて環境依存部分を切り替えて、現行のソースをリネームで保管して差し替えるようなスクリプトくんでました。 社内でヒアリングしたところ、Jenkinsによるテストにデプロイも組み込むような噂を聞いたので、とりあえず現行プロ
-
継続的デリバリのパターン
継続的デリバリを導入しようとする前に、いくつかの準備が必要です。真っ先に必要なのは、ビルドサーバに合うソースコード管理システムです。ビルドサーバは継続的統合を実施するサーバにもなります。ひとつひとつのチェックインをビルドできるサーバでなければなりません。一般的に言って、この用途では“既成”のビルドサーバが欲しくなります。チェックインを監視して、自動でビルドをする仕組みを構築するのは、想像以上に大変です。利用しているソースコード管理システムにフックできるトリガがあるとしても、ビルド失敗時の通知機能のような他の機能を実装するには割に合いません。 リソースが限られているとしても、継続的デリバリにとってステージングサーバは重要です。ステージングサーバは本運用環境に可能な限り似せておく必要があります。ここで第一の問題は“予算がいくらあるか”ということです。本運用環境のデータベースサーバがとても高価な
-
1
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
