タグ

Dockerとgolangに関するwushiのブックマーク (5)

  • ssig33.com - Docker で Go で作ったバイナリを実行するなるべく小さいコンテナを作る

    Go でアプリケーションを作ると、そのまま他になにもなくとも実行できるバイナリが出来あがります。この特性によりデプロイが大変楽です。 このような特性があるので、 Go を使う場合 Docker のようなオーケストレーションツールを使わなくても多くのサーバーにアプリをデプロイしていくことも可能かと思われますが、そこはまあ Docker という巨人に乗っておくと楽なことが多いです。具体的には swarm と docker-compose が便利なので Docker 上で実行したい。 ここで問題となってくるのが何も考えずに Docker イメージを作るとイメージサイズが膨れあがってしまってシングルバイナリによる手軽さなどが損なわれてしまうという点です。 たとえば golang:alpine のような比較的小さいイメージを使ってもファイルサイズはバイナリサイズ + 300MB ほどにもなってしまい

  • DockerとSwarmで既存アプリをサーバーレス化してみよう! - Qiita

    以下でポイントごとにソースを見る/比較を行ってみます。 ポイント リクエスト処理部分 voting appとresult appという2つのサービスで処理していたのを、 entrypointというサービスで受け、それぞれ担当するDockerコンテナを起動するという形になります。 リクエスト処理部の違い voting appとresult appはそれぞれ何の変哲もないWebアプリです。 (voting appがPython/Flask、result appがNote.js/expressで作られている) 対して、entrypointもWebアプリ(Go言語)なのですが、net/httpでリクエストを受け、 go-dcgiというライブラリでDockerコンテナを起動するようになっています。 この部分のソースを見てみましょう。 非常に短いですので全文掲載しています。(コメントは私が追記したもの

    DockerとSwarmで既存アプリをサーバーレス化してみよう! - Qiita
  • 自作Linuxコンテナの時代 - ゆううきブログ

    最近、Docker以外のコンテナ型仮想化技術の流れとして、自作コンテナエンジンの時代が来るのではないかと感じている。 自作コンテナエンジンとは、コンテナ型仮想化技術を構成する個々の要素技術を組み合わせ、自分の用途にあわせて最適化したコンテナエンジンのことだ。 他のOSのコンテナ仮想化技術について疎いため、以下ではLinuxに限定して話を進める。 概要 Dockerも含めて、Linuxコンテナはコンテナを構成する複数の要素技術の組み合わせである。自分のやりたいことに対して、Dockerをはじめ既存のコンテナエンジンが複雑すぎるケースがある。そこで、自分の用途にあわせてコンテナエンジンを自作することを考えてみる。libcontainerに代表されるように、Linuxコンテナエンジンを自作しやすい環境が整いつつある。今後は、巨大なコンテナエンジンに対して、UNIX哲学に基づいて制御可能な小さなコ

    自作Linuxコンテナの時代 - ゆううきブログ
  • Goのデプロイを「もっと」簡単にする。ビルドプロキシCargo。改めTorokko。

    Goアプリのデプロイはバイナリをひとつ配布して完了なのでとても楽なのですが、バイナリ自体をどこで管理するかについては意外と頭を悩ませることになります。 Goを使うにあたって、コードさえあればあとはバイナリも簡単に配布できる状態というのが望ましいと思い、仕組みを作ってみました。 2015/08/16追記: CargoRustのパッケージマネージャーと名前がかぶってたのでTorokko(トロッコ)に改名しました! TorokkoはGoアプリのビルドと成果物ダウンロード用のAPIを提供するビルドプロキシです。 リクエストのURLで対象リポジトリ、GOOS、GOARCH、バージョンを指定します。 ビルドはDockerコンテナを用いて行い、バックエンドストレージに成果物が保存され、ビルドリクエストと同じURLでダウンロードを行うことができます。 Docker Hub の Automated Bui

    Goのデプロイを「もっと」簡単にする。ビルドプロキシCargo。改めTorokko。
  • Goでwebサーバー作るときに考えたこと - Qiita

    Goでwebサーバーを作るときに考えたことをまとめておきます。 dockerコンテナで動かす場合を少し考慮してます。 フルスタックフレームワークか軽量系フレームワークか 最初に突きつけられる問題です。 フルスタックフレームワーク revel beego 軽量系フレームワーク goji negroni どんなフレームワークもそうですが、フルスタックなフレームワークならば、 その道に乗っかることで余計なことを考えずにすみます。 だけどその道から外れることをする場合に苦労が伴います。 golangの場合、Go初心者ならばフルスタックでもいいけれど、 ある程度Goに慣れてくると標準のライブラリといくつかのライブラリを使うだけで webサーバーを作る場合、十分な場合があります。 前にrevelを使っていたときは、最初はrevelの機能を使っていたけれど、途中で他のライブラリを使ったほうが楽なんじゃな

    Goでwebサーバー作るときに考えたこと - Qiita
  • 1