フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
ゴクロの大平と申します。はじめまして。 4月からjoinさせていただいた、特に特記事項の無い平凡なプログラマです。さだまさしが好きです。 SmartNews開発者ブログをご覧になる方々は、サービスの裏側で動作するクローラーや多種多様な機械学習のロジックであったり、フロントエンドのUIの話であったり、サービス固有の話に興味が有る方が多いと存じますが、都合上(原稿の担当順番の都合上)、今回は一般的な話をさせていただきます。 ※先掲の話題については次回以降取り上げられますので、お楽しみに。 一般的な話題とはいえ、大企業とスタートアップでは取り巻く環境や解決すべき課題も異なっていますので、その辺もあわせてお伝え出来ればなと思います。 なお、今回のテーマは、サーバー/ミドルウェアの構成管理ツールとして最近有名になってきた「chef」と「fabric」です。 かなり長文のエントリーになってしまい
第2回 JAWS−UG 神戸 OpsWorks (Chef) 特集 ! on Zusaar 神戸で開催された JAWS-UG 神戸でChefについての発表を行いました。以前、Engine Yardのオフィスで開催したものをChef11に対応した形でアップデートした内容です。 おもな変更点としてはインストールの方法やChefの全体のアーキテクチャの解説を最新に変更しています。以前の資料のとおりだとやや残念になってしまうのでこちらを参照して頂けるとスムーズにChefを導入できるのではと思います。 すぐに手元で試したい方にはこちらのVagrantfileをオススメします。 超シンプルなVagrantfile https://gist.github.com/yandod/5934790 Engine YardはAmazon Web ServiceやWindows Azureなどのクラウド環境にC
まとめてたくさん処理したい! を解決する「Capistrano」:特集 DevOps時代の必須知識 インフラ運用の自動化を実現し、DevOpsを支援するツールはいくつかあります。ここではその中から「Capistrano」というツールについて、サンプルを用意しつつ紹介します。 はじめに インフラ運用の自動化を実現するツールには「Chef」や「Puppet」などいろいろあります。今回の記事ではそういったツールのうち、Capistranoというツールを簡単なサンプルを用意しつつ紹介します。 Capistranoとは Capistranoとは簡単にいうと、オープンソースで提供されている、複数のサーバ上で同時にスクリプトを実行するためのソフトウェアツールです。主に、同じ役割のサーバが複数台存在するような環境での自動化であったり、アプリケーションのデプロイ自動化に利用されています。 特にRuby On
DevOpsというキーワードに関連して、「Chef」というツールの名前を聞いたことのある人も多いのではないでしょうか。この記事では、インフラにおける構成管理、展開作業を自動化するChefの構造および基本的な使い方について解説します。 インフラストラクチャ自動化フレームワーク「Chef」 Chefは、物理、仮想、クラウドといったさまざまな大きさのインフラに対して、サーバやアプリケーションの展開を容易にするための自動化フレームワークです。 Chefの重要な要素の1つに「Infrastructure as Code」という概念があります。インフラをどのように構築し、維持するべきかという定義はRubyの文法で記述され、ソースコードのように扱うことができます。つまり、あたかもRubyでプログラミングをするように、インフラの構成管理をコードによって行えることがChefの利点の1つです。 自然言語による
最近さまざまなイベントやブログエントリで見かける「DevOps」。この言葉をひもとき、なぜ「Dev」と「Ops」が衝突するのか、その解決に必要な要素とは何かを分かりやすく解説します。 DevOpsとは 2009年にオライリーが開催した「Velocity 2009」というイベントにおいて、Flickrのエンジニアが、“開発と運用が協力することで、1日に10回以上のペースでリリースが可能になること”を紹介しました。いまさまざまなシーンで見かける「DevOps」という言葉は、このプレゼンの中で登場したものです。 DevOpsとは、開発(Development)と運用(Operations)が協力し、ビジネス要求に対して、より柔軟に、スピーディに対応できるシステムを作り上げるためのプラクティスです。多くの人々により議論は続けられていますが、ITILとは異なり、現時点においては、DevOpsに厳密な
本項はChefConf 2013: Beginner Chef Antipatternsを和訳したものです。 はじめに よく Chefの学習は大変 Chefの学習曲線は急勾配 と言われているので、Opscodeでは緩和するためのコンテンツを色々準備しています。 learnchef.com docs.opscode.com パブリック/プライベート トレーニング Podcasts (Food Fight Show など) 各地のユーザグループ (訳注: 日本なら #opschef_ja ) ChefConf! (訳注: これは ChefConf 2013 で行われたセッションなので) それでも、正しいことをやっているのか知るのは難しく、何か間違ったことをやっているのか知るのはさらに難しいものです。コミュニティの中で「ベストプラクティス」は常に進化してきました。 ベストプラクティスについてもっ
2013年6月7日 22:04更新: Upstartのデフォルトの設定ファイルを書き換えない方法に変更しました。hitoさんありがとうございます。 lxcなどのバージョンを記載しました。 はじめに Chefを使っていると、役割やサービスごとに環境を分離したくなります。 しかし、個人レベルで大してトラフィックがない段階で、サービスごとに仮想サーバーを借りていてはお金が足りません。 そこで、安価なVPS上でLinux Container (LXC) を使うことで、複数のサーバーを作ります。 スケールしたくなったときは、コンテナを潰して、新しく仮想サーバーを借りてChefで同様の設定をすれば手軽にスケールできると考えています。 Heroku使えば?と言われるかもしれませんが、色々なミドルウェアを利用したり、バックグラウンドで処理をしようとすると、たちまちお金がかかるので、VPSをやりくりして遊び
「ニフティクラウドユーザーブログ」は、移転しました。 自動でページを移動しない場合は、下記のリンクをクリックし、 新しい「ニフティクラウドユーザーブログ」をご覧ください。 今後とも「ニフティクラウドユーザーブログ」をよろしくお願いいたします。 > ニフティクラウドユーザーブログ
Jenkins おじさんと戯れること半日、うまくいったので備忘録を残しておく。 やりたかったのは Chef で構築したサーバーを Jenkins で CI する、というもの。このときサーバーはテストが終わる度に破棄して、テスト開始時に再度真っ新な状態から立ち上げたい。(こういうサーバーを壊して作ってというテストはなんという名前で呼ばれるのだろう?) 仮想サーバーを破棄/作成をプログラマブルにやるのはもちろん Vagrant プロビジョニングは Chef Chef の環境を整えるのに knife-solo 0.3.0.pre3 テストは serverspec コードは Github に上げる (https://github.com/naoya/jenkins-vagrant-test) CI は Jenkins という構成になっている。ひとまず Jenkins や Vagrant はローカル
これまでChefとか全くやったことなかったのだけれど、PrePANとかで必要になったのとなんとなく興味もあったので、naoyaさんが最近出した入門Chef Soloを読んでみました。 入門Chef Solo - Infrastructure as Code 作者:伊藤直也伊藤直也Amazon 読んでみた感想としては非常によくまとまっていて分かりやすいけど、全くChefをやったことない人にとってはChefの実行を試すフェーズが少しやりづらい印象を受けました。理由としてはAWS環境を持っていない場合、2,3章のChefを試す章ができず、さらにそのあとにvagrantでローカルに仮想環境を作るのを学んだとしても、その仮想環境を使って試す部分が少ないためです。 そこで僕は全くchefをやったことない人はまずvagrantでの実行環境を作れるようになってから、本を読み始めるとより知識が深まるのではな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く