Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? やや遅くなってしまったが、年末に参加した Azure のインフラの勉強会のまとめ。 事の発端 2016/12/26にNHNテコラスさんにて開催された、「インフラ野郎Azureチーム Night」での Microsoft 真壁さんの講演が、あまりにも面白い上に広いトピックを扱っていて、一部消化不良になった人がおり、2回戦よろしく…というような声があがっていた。(はいそこ、m9 はナシでw) そういうわけで、興味のあるところを中心にざっくり要点をまとめておこうと思ったのが発端。なお、タイトルに「概要編」とあるように、この記事は当日のメモをも
こんにちは。IT基盤部でOpenStackの運用をしています酒井です。 私からは弊社OpenStack環境で使用しているSDNについてご紹介したいと思います。 前回の記事 で紹介しましたように、弊社ではBigSwitch Networks社のBig Cloud Fabric（以下BCF）を使用しています。本エントリーでは弊社がどのようにBCFをOpenStackとインテグレーションしているか、どのように運用しているのかについて紹介させていただきます。 OpenStackとSDNの導入の狙い 従来はネットワークのconfig変更をする場合、サーバエンジニアからネットワークエンジニアにその作業を「依頼」する形を取っていたのですが、この「依頼」を無くすことが狙いでした。依頼内容としてはスイッチへのVLAN設定やACL設定、LBへのオブジェクト追加など比較的簡単な作業です。しかし、依頼件数が多い時
あまりにもつらかったので、おとなしくフォークして自前でパッチを当てることにしました。フォークするついでに名前を変えたのが mikasafabric for MySQL （みかさファブリック フォー マイエスキューエル）になります。 期待通りに使えるMySQL Fabric を目指した結果なので、まあまあ期待通りに動きます（ただし、MySQL Routerとの組み合わせしかサポートしていません。他のコネクターは動くかも知れないし動かないかも知れない。一部、APIの戻りにも手を入れているので） 名前を変えた理由- MySQLは商標なのでフォークとはいえMySQL Fabricは微妙（MySQL xxxはダメで、xxx for MySQLならOK） - mikasafabric for MySQL は MySQL Fabric 1.5.6 をベースにしているので、リポジトリー分けるまでは1.5.
Infiniband Day02 「Infiniband入門」 アジェンダ • Infiniband入門について • 用語 • ケーブリング • HCA • ノードアドレス • Subnet Manager • ドライバ＆ユーティリティ（Linux&Win) • トラブルシューティング Infiniband入門について ユーザ空間 カーネル空間 ユーザレベルIBサービス Verbs Library HCA Infiniband Core モジュール(CM, SA Client, MAD, Verbs) Driver Upper Layer Protocol (ULP) SRP iSER NFSoR IPoIB SDP Xsigo vNIC vHBA MAD Services MPI uDAPL Application ブロック ストレージ アクセス Subnet Manager Infin
複数プロジェクトを抱えるチームでのデプロイ自動化 1つのチームで，10以上のプロジェクト，コードベースを抱える場合にどのようにデプロイの自動化を進めたか，工夫したこと，考慮したことなどをまとめておく． デプロイツールには，Python製のfabricを採用しているが，他のツールでも同様のことはできそう．なお，fabricの基本的な使い方などは既にインターネット上に良い記事がたくさんあるので書かない（最後の参考の項を見てください）． fabricの選択 シェルスクリプトとCapistranoを考慮した． まず，シェルスクリプトは人によって書き方が違うため，統一が難しくメンテナンスコストも高い．また共通化も難しい． 次に，Capistranoは，裏でやってくれることが多く，学習コストも高い．プロジェクトによってはかなり特殊な環境へのデプロイも抱えているため，Capistranoの前提から外れる
fabricで例えばapacheを起動したい場合に sudo("/etc/init.d/apache2 restart")と当然書くじゃないですか。で確認するとちゃんとプロセス起動しない訳じゃないですか。 で、どうすれば良いかと言うと公式docに書いてあった。http://docs.fabfile.org/en/1.8/faq.html Init-style start/stop/restart scripts (e.g. /etc/init.d/apache2 start) sometimes don’t like Fabric’s allocation of a pseudo-tty, which is active by default. In almost all cases, explicitly calling the command in question with pty=
継続的デリバリ／デプロイを実現する手法・ツールまとめ：DevOps時代の開発者のための構成管理入門（終）（1/2 ページ） バージョン管理や継続的インテグレーションとも密接に関わる継続的デリバリ／デプロイメントの概要や主なツール、経緯、実践事例を紹介。実践手法として「ブルーグリーン・デプロイメント」「Immutable Infrastructure」が注目だ。 完全に自動化されたリリースプロセスが必要となる「継続的デリバリ」とは いよいよ本連載「DevOps時代の開発者のための構成管理入門」も最終回となりました。今回のトピックは「継続的デリバリ」です。 継続的デリバリは、本連載で扱ってきたバージョン管理や継続的インテグレーションなどの単一のプラクティスではなく、それら一連のプラクティスを包含した、ソフトウェアデリバリ全体に対しての「考え方」「アプローチ」といえるものです。 「継続的デリバリ
chefを使いそうなのでその辺素振りしてみる。 chefの前にまずvagrantとvirtualboxをそれぞれダウンロードしてインストール Boxファイルの追加 $ vagrant box add centos63 https://dl.dropbox.com/u/7225008/Vagrant/CentOS-6.3-x86_64-minimal.box $ vagrant init centos63 $ vagrant box list centos63 (virtualbox) saharaプラグインの追加 $ vagrant plugin install sahara $ vagrant plugin list sahara (0.0.16) sandbox on $ vagrant sandbox on 0%...10%...20%...30%...40%...50%...60%
Fabric は、Python 製のデプロイ・システム管理ツールです。 最近、構築や運用を自動化するための様々なツールが出てきています。 構成管理ツールの Puppet や Chef が有名ですが、使うまでに覚えることが多いのが欠点です。 しかし、Fabric は非常にシンプルなツールで、今からすぐに使うことができます。 Fabric はデプロイ・システム管理ツールで、類似のツールとして Ruby 製の Capistrano があります。 Fabric の最大の特長は、シェルスクリプトを書き慣れた人がいきなり利用できるところです。 シェルスクリプトとしてまとめていたコマンドをそのまま run() メソッドや sudo() メソッドで囲むだけで、使うことができます。 シェルスクリプトを使っていていると、いくつもの問題に遭遇します。 名前空間の管理 変数の扱い 複雑なデータ構造がない(せいぜい
ゴクロの大平と申します。はじめまして。 ４月からjoinさせていただいた、特に特記事項の無い平凡なプログラマです。さだまさしが好きです。 SmartNews開発者ブログをご覧になる方々は、サービスの裏側で動作するクローラーや多種多様な機械学習のロジックであったり、フロントエンドのUIの話であったり、サービス固有の話に興味が有る方が多いと存じますが、都合上（原稿の担当順番の都合上）、今回は一般的な話をさせていただきます。 ※先掲の話題については次回以降取り上げられますので、お楽しみに。 一般的な話題とはいえ、大企業とスタートアップでは取り巻く環境や解決すべき課題も異なっていますので、その辺もあわせてお伝え出来ればなと思います。 なお、今回のテーマは、サーバー/ミドルウェアの構成管理ツールとして最近有名になってきた「chef」と「fabric」です。 かなり長文のエントリーになってしまい
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Chefに挫折したあなたへ。Fabricのすすめ という記事を読んだので、呼ばれてもいないのに勝手に返事を書いてみます。 追記(3/13 10:00): タイトルを typo していたようなので訂正しました。 ちなみに僕のポジションとしては chef 推進派です。 仕事の空き時間や自分の時間で、開発環境の自動化を模索する趣味 chef 使いです。 これまで他の自動化ツールはこれまでほとんど使っておらず、 ミスや手順書のボリューム削減のためにシェルスクリプト化を進めるぐらいでした。 ちなみに、chef を使いはじめる際に、比較検討のために puppet や fabric などのいくつかのツールについて ドキュメントやブログを読みあさった経験はあります。 あと、chef と組み合わせて使うために capistrano を最近使っています。 学習に時間がかかる 同意します。chef のもっぱらの
Posted by: Matt Mansour 7 years, 7 months ago (0 comments) After a hearing a great Gunicorn talk by Brian Riley of EdgeCast.com at the LADjango meetup I decided it was time to dive in to a modern server for Django. After getting around a few bumps I realized setting up Gunicorn with NGINX was easy. Even though I appreciate - and was blown away by - Graham Dumpleton's mod_wsgi for Apache, I feel it
This is a howto on setting up Django on a Linux (Ubuntu) system using Nginx as a reverse proxy and Gunicorn as a Django service. The conventional way to run Django in production these days is using Apache2 and mod_wsgi. While there’s nothing wrong with that approach, I prefer Nginx. I also like to be able to control Django server separately from the web server. There are several production-ready s
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
