ssig33.com - Docker で Go で作ったバイナリを実行するなるべく小さいコンテナを作る
Go でアプリケーションを作ると、そのまま他になにもなくとも実行できるバイナリが出来あがります。この特性によりデプロイが大変楽です。 このような特性があるので、 Go を使う場合 Docker のようなオーケストレーションツールを使わなくても多くのサーバーにアプリをデプロイしていくことも可能かと思われますが、そこはまあ Docker という巨人に乗っておくと楽なことが多いです。具体的には swarm と docker-compose が便利なので Docker 上で実行したい。 ここで問題となってくるのが何も考えずに Docker イメージを作るとイメージサイズが膨れあがってしまってシングルバイナリによる手軽さなどが損なわれてしまうという点です。 たとえば golang:alpine のような比較的小さいイメージを使ってもファイルサイズはバイナリサイズ + 300MB ほどにもなってしまい
ssig33.com - Ruby On Rails でサブドメインを使った Web サイトを作る
という地獄の話です。 基本的な部分 # config/initializers/session_store.rb Hogehoge::Application.config.session_store :cookie_store, domain: ".#{ENV['DOMAIN']}", key: '_hogehoghoge' というような感じにする。アプリを起動する時に環境変数でドメインを指定する。 .#{ドメイン} と cookie のドメインを指定しておくことでサブドメインでもクッキー共有できるようにする。クッキー共有したくないならこうしない。 ./bin/rails server とかを使うなら、この場合 localhost としてアプリが起動するのだから、 DOMAIN=localhost ./bin/rails server とかする。 hoge.localhost とかで名前解
ssig33.com - 普通の人が Docker を使う理由
こんにちわ皆さん。 Immutable Infrastructure という単語のブームも一段落した昨今と思います。今日は普通の人が Docker のようなツールを使ったほうがいい理由について簡単に書きます。 この手のツールは「頻繁にアプリをデプロイする」「大規模なサーバー群を運用している」人向けのツールというイメージが比較的強いのではないかと思っています。 しかしながら 安い VPS を借りて Web サイトや IRC プロキシなどを細々と運用している というようなわりと普通の人でも Docker を使う利点は十分あると僕は考えています。それは 同じ VPS の同じゾーンに BitTorrent 野郎がやってきて、ネットワークが劣化して使い物にならない というようなことが VPS を使っているとたまにあります。こういう時に、運営側に「ネットワーク遅くて使い物にならないんだけど」とかクレー
ssig33.com - Docker をプロダクトのデプロイに使う
コミケの列に並んでたあたりのころから Docker 本格的に使ってます。このサイトもさっき Docker でデプロイするような感じにしました。 Docker の利点と欠点で 開発環境の配布が容易にできる プロダクトのデプロイにつかうにはなにかとキツい みたいな意見をわりと頻繁にみかけるのですが、逆じゃねえかと思ってます。これ開発環境の配布に使うの無理でしょ。各コンテナ使い捨て前提なんだし。 Docker をデプロイに使う際の問題点としては以下があります Dockerfile に 42 個しか命令かけないみたいなやつ なんだかんだでコンテナのビルドに時間がかかる コンテナの管理とかどうするのか リバースプロキシの設定とかどうするのか 一個目に関しては頑張ってください。僕はセットアップ用やデプロイ用のシェルスクリプトを ADD して RUN させるようにしてます。シェルスクリプトセットアップ
ssig33.com - 運営と技術者の距離を近くして開発効率を上げよう！！！
みたいの結構良さそうな感じがするんですが。実際そうではないです。 運営はユーザーからのクレームやサービスの問題点を大声で議論をします。エンジニアは大抵気が弱いので四六時中聞かされていると会社を辞めてしまいます。 また運営は四六時中エンジニアから「そんなこと言いますけどそれ実装するの無理です」と言われ続けますからストレスで会社を辞めてしまいます。 そうして誰もいなくなる。残るのは悪意に鈍感なウスノロだけでそんな奴は使い物になりません。なので大抵の場合運営と開発はある程度物理的に距離をとってしまうほうがよいです。 ですがまあ距離を近くしよう的な策が取られることが多いです。これは何故かというと、「企業家」「経営者」といった連中は上記のような地獄をとおりぬけてきた人間や、それをなんとも思わないような人間だからです。その辺こういう話に近いと思います。 雇われてるだけの人間は精神壊す前に逃げましょう。
ssig33.com - ベンチャーについて極めて基本的なこと
本当に基本的なことを書きます。これから書くのは本当に基本的なことです。ですが以下のことへの理解が足りない事例をよく見ます。その結果の悲劇もよく見ます。 経営者の皆さんへ あなたの会社の社員はあなた程仕事へのモチベーションがありません。あなたが掲げる理念をあなた程信じてもいません。当然です。あなたと同じようにモチベーションがあり、あなたと同じように強烈な信念があれば、あなたと同じように起業するはずです。 もしあなたが仕事のモチベーションも信念もなく適当に会社を売り抜ければそれでいいなどと考えているならば、あなたのその価値の無い仕事は売り抜けることなど出来ないでしょう。 経営者の皆さんは起業した自分の理念に命を賭す価値があると信じていることでしょう。実際その価値は本物かもしれません。ですがあなたの会社の従業員は給料に見合っただけの労力を提供すればいいと思っています。そんなもんです。社員があなた
ssig33.com - サブドメインを沢山使いたい
http://kure.ssig33.com http://darui.ssig33.com http://nemui.ssig33.com みたいのを沢山作ってコンテンツをそこに置きたい。めんどくさいことはしたくなくて、設定ファイルをいじるのは最初の一回だけにしたい。コンテンツの更新はブラウザ経由でやりたい。置きたいコンテンツは精々静的な HTML 一枚。 そんな需要が僕にはあったので解決してみた。 もともと ssig33.com は Sinatra で作ったアプリで、その前段に nginx がいるという構成になっていた。 nginx の設定は upstream ssig33.com{ server localhost:9233; } server { listen 80; root /home/ssig33/dev/site/public; index index.html index
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
