Building a Simple DB in Rust - Part 1 - Parsing
This article is part of the Building a Simple DB in Rust series. While I've used rust for a while and have had a few small projects in it, I felt like I was missing a truly "systems" project. So when I came across this series for making a simple DB in C, I figured why not try to make my basic DB in rust. I will roughly follow the structure of that series at first, but I will most likely deviate an
docker-build-battle?slide=51
Google Play Consoleデベロッパー アカウントの確認 / Verifying your Play Console developer account
go getで取得したcliツールのバイナリを持った軽量なDockerイメージをつくる - tehepero note(・ω<)
2017 - 01 - 26 go getで取得したcliツールのバイナリを持った軽量なDockerイメージをつくる Docker Go Alpine CircleCI 諸事情で欲しかった。 動機 gooseというGoで書かれた cli のDB マイグレーション ツールを使っているのだが、こいつの バイ ナリだけを持っているDockerイメージが欲しい Goにも Alpine Linuxベースの軽量なイメージ がある。しかしそれでも240MBくらいある ベースイメージはGoでなくていいので、gooseの バイ ナリをシュッと実行 ディレクト リに配置した軽いイメージが欲しい といったところ。ちなみにAlpine Linux はもともと組込系用途で利用されていた ディストリビューション で、最近ではDockerイメージのベース ディストリビューション として広く利用されてます。 alpine
至高のDockerイメージ生成を求めて - Qiita
本稿は良いDockerイメージを良い方法でビルドすることを探求した記録である。 Supership株式会社 Advent Calendar 2016の21日目にあたる。 2019年現在は@inductor氏の改訂版を見たほうが良い。 この記事で論じた望ましいコンテナイメージの姿は2019年でも変わらない。ただし、multi-stage buildのような新しい仕組みが普及したりツールの評価が定まってきたりと、実現に用いるツールの状況が2016年からやや変化している。 良いDockerイメージ 良いDockerイメージとは何だろうか。Dockerの利点は次のようなものだから、それを活かすイメージが良いものであるに違いない。 ビルドしたイメージはどこでも動く 適切にインストールされ、設定されたアプリケーションをそのままどこにでも持っていける。 コンテナ同士が干渉し合うことはないので、任意のイメ
golangで書いたツールをCircleCI上でビルドしてその成果物をGitHub Releasesにリリースする - その手の平は尻もつかめるさ
表題の通り．いくらかポイントがあったのでメモとして記す． 基本的にこの記事の内容を真似した． medium.com あらかじめ，CircleCIの側の設定でGITHUB_TOKENという環境変数を登録しておく．なおGitHubのPersonal access tokenにはrepoのpermissionを付与しておく． とは言えこれでは動かない．理由はghr (ghrについてはこちら: 高速に自作パッケージをGithubにリリースするghrというツールをつくった | SOTA) がcontextに依存しているからで，contextはgo 1.7以降でないと利用できない．しかしながらCircleCIのgolang環境は1.6系が使える内の最新なので *1 このままではghrをgo getすることが出来ない． というわけでCircleCI上でgo 1.7を使うようにしましょう，ということでそう
Wercker で Go のプロジェクトをクロスコンパイルし、GitHub にリリースする - 詩と創作・思索のひろば
ghq をメンテナンスするにあたっていくつか無料の CI サービスを試してみたのですが、今回は Wercker を使うことにしました。いろいろ試行錯誤した結果表題のことがなんとか実現できた（ghq のリリースは GitHub 上 にあります）ので、ハマりポイントと共にこのエントリで紹介します。 Wercker Wercker は CI サービスのひとつで、ビルド環境やデプロイの 1 ステップを box および step という形でユーザが公開・共有し、それらを組み合わせることで CI の設定をシンプルにしようとしているところが特徴です。 ghq の wercker.yml を見てもらえばだいたい雰囲気は分かると思いますが、大まかに言って “box”, “build”, “deploy” の 3 項目をプロジェクトごとに設定します。 box はビルドが走る環境です。OS や、テストに必要なパ
Docker 使って golang で書いたツールの cross platform build をする - その手の平は尻もつかめるさ
まず以下の様なシェルスクリプトを用意する． #!/bin/bash # ここで依存しているパッケージを go get する # 例えば以下の様な感じ # go get -v gopkg.in/yaml.v2 # go get -v gopkg.in/redis.v3 for GOOS in darwin linux; do for GOARCH in 386 amd64; do export GOOS export GOARCH go build -v -o bin/tool-$GOOS-$GOARCH main.go done done darwin と linux について，それぞれ i386 と amd64 アーキテクチャ向けのバイナリを作るようなスクリプト．main.go はビルド対象のファイル．成果物はカレントディレクトリの bin 以下に生成されるので，あらかじめ mkdir
dockerをビルド環境として使う - Qiita
dockerコンテナにコンパイラなどを入れ、更にそのコンテナにビルド対象のソースコードをマウントすることで、docker自体をビルド環境として使うことができる。 例えばC#のビルドであれば、monoのコンテナ（monoは.NETのオープンソース実装。monoのmsbuildはxbuildになる）を使って、PATHの通ったところに以下の様なシェルスクリプトを置けば、ビルドコマンドに早変わりする。 #!/bin/sh eval "$(docker-machine env default)" docker run -it --rm -v `pwd`:/src --workdir=/src --entrypoint=xbuild mono $* このスクリプトの前提は以下のとおり。 docker-machine env defaultが構築済みであること カレントディレクトリをdockerデーモン
How We Build Code at Netflix
How does Netflix build code before it’s deployed to the cloud? While pieces of this story have been told in the past, we decided it was time we shared more details. In this post, we describe the tools and techniques used to go from source code to a deployed service serving movies and TV shows to more than 75 million global Netflix members. The above diagram expands on a previous post announcing Sp
Docker ARG がimage量産に便利 - Qiita
Docker 1.9 がでて、 ARG という項目が追加されました(document)。 概要としては、 docker build 時に --build-arg <KEY>=<VAL> として渡した変数が Dockerfile 内で利用できるというものです。 個人的には環境変数を拾ってくれるのが欲しかったのですが、今回は据え置きで、あくまで Dockerfile 内の ENV 命令でセットされたものだけが、解釈対象だそうです。 どういう用途で便利かというと、 設定だけを変えた同じイメージを量産したい場合 これです！これができるようになりました。 例えば、 ulimit の値を変えたイメージを作りたい場合にはイメージを2つ作るための Dockerfile を作るか、docker run の時の ENV を拾って sed などのコマンドでほげほげしたりするスクリプトを書いたり、だったと思います
プロキシ環境下でdocker buildするときにbuild-time argumentsを利用する - Qiita
FROM ubuntu:14.04 ENV HTTP_PROXY http://proxy.example.com:8080 RUN apt-get -y update && apt-get -y install nginx しかし当然ながら、このDockerfileから構築したイメージには プロキシ設定が埋め込まれる。 プロキシ環境下でしか使わないのであれば問題無いが、 それ以外の環境に持ち出す可能性がある場合は トラブルの元なので、できれば避けたい。 build-time argumentsの利用 build-time argumentsはdocker engine 1.9から実装された機能で Dockerfileのビルド時にパラメータを設定することができる。 Announcing Docker 1.9 build-time argumentsを利用することで、 docker run時
gulp問題ひきずり：ウォッチがまたおバカ過ぎる - 檜山正幸のキマイラ飼育記 (はてなBlog)
「最近のビルドツールって何なの？」において、gulpは「腕力はあるが知性を持たない」、ゴレライ的というかゴライアス的というか…、そんなツールだと述べました。二、三、後から思ったことがあるので追加します。 内容： プロジェクトは肥大しちゃうことがある ウォッチをいちいち手で書くのかよー OMakeと比較してみる ウォッチはこうでなきゃ じゃ、OMakeがいいのか？ プロジェクトは肥大しちゃうことがある 「そもそも大した事はしないのでシンプルなツールgulpでも十分」ということなら、「そうですよね」と同意して話はオシマイです。でもね、gulpを使うプロジェクトが、ほんとに小さくて簡単なものなんでしょうか。 目の前に、10種のプログラミング言語が混じった2000ファイルのソースコード群がいきなり与えられたとき、「よしっ、gulpを使おう」とはならないと思うのですが、小さなプロジェクトが（良くも悪
最近のビルドツールって何なの？ - 檜山正幸のキマイラ飼育記 (はてなBlog)
TypeScriptでは、コンパイルが必要です。プログラムをブラウザーとNode.jsの両方で使おうとすると、さらに加工が必要です。ミニファイだの文書も作るだのすると、ちょっとしたビルドプロセスとなるので手作業では辛くなります。 今更Makeでもないよなー、と思い、最近のビルドツールを試してみました。 内容： 流行りすたりが激しすぎる gulpを使ってみる：こんなサンプル gulpのビルドスクリプト タスクランナーってのはビルドツールとは違うのか？ ビルドツールは進化したのか 参考資料： 例題のファイルとコマンドの一覧 ソースファイル 追加の話： gulp問題ひきずり：ウォッチがまたおバカ過ぎる 流行りすたりが激しすぎる 「確かGruntってツールがあったよな」と、インストールと使い方を調べていると、やたらにgulpって単語が目立つんですよね。Gruntのライバルの新興勢力らしいです。 「
Travis CIでコンテナベースのインフラストラクチャとDockerでより高速なビルドを | POSTD
Travis CIが出た時から、当社はビルドにおける安定性と信頼性の提供を第一にしてきました。しかし、常に期待に応えてこられたとは言えません。ネットワークの問題や、ビルドのキャパシティが不十分で(オープンソースプロジェクトに対して)ビルド開始までに時間がかかる、ビルド環境におけるCPUやメモリのリソースに制限がある、オープンソースプロジェクトに対応するキャッシュがないなどの問題がありました。また、現在当社で使っている大部分のLinuxのスタックはプライベートクラウド上で動作するため、要求してからキャパシティに空きができるのを待つというプロセスを経なければならなりませんでした。そのため、キャパシティを増やすという課題もありました。 今回ご紹介するのは、このような課題に対応した新たなビルド・インフラストラクチャです。これからは、プライベートやオープンソースのリポジトリにもお使いいただけます。
革命の日々！ おまえら rpmdev-setuptree を使えという話
いままで、rpmbuildするときに mkdir -p ~/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS} して、 echo '%_topdir %(echo $HOME)/rpmbuild' > ~/.rpmmacros とかやってたんだけど、それはもう古いらしい。 % yum install rpmdevtools % rpmdev-setuptree すると、上記の両方をやってくれるのに加えて .rpmmacrosに並列処理設定を追加してくれる。 こんな感じ %_topdir %(echo $HOME)/rpmbuild %_smp_mflags %( \ [ -z "$RPM_BUILD_NCPUS" ] \\\ && RPM_BUILD_NCPUS="`/usr/bin/nproc 2>/dev/null || \\\ /u
npm + gulp + bower でビルド自動化 - GeekFactory
(追記) この記事は公開から時間が経っており、内容が古くなっています。2016年時点ではWebpackが圧倒的におすすめです。 JavaScriptやCSSのビルドを自動化することで、手作業による無駄な時間やミスを削減できます。また、誰でもビルドできるようになるため、リリースのボトルネックを解消できます。 改善したいこと JavaScriptフレームワークやCSSフレームワークの依存関係を自動的に管理したい。ダウンロードして配置を手作業でやりたくない。 CoffeeScriptやLESSのコンパイルを自動的に実行したい。手順書を見ながらコマンドを叩くとかやりたくない。 ダウンロードしたライブラリをリポジトリに入れたくない。 出荷対象のリソースを明確にしたい。ゴミファイルをリリースしたくない。 どうやって実現する？ bowerでライブラリの依存関係を管理する。 gulpでビルドを自動化する。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DIY: Build a Custom Minimal Linux Distribution from Source | Linux Journal
Docker マルチステージビルドで幸せコンテナライフ / Understanding docker's multi-stage builds
Setting Go(1.5) variables at compile time for Versioning
Jenkins Build Stability/Statisitics Report plugin