Docker向け DB設定まとめ
DockerでDB使うたびに調べるの疲れたのでまとめる
だいたい、ゲームサーバやWebで使われるDBは下記だ
MySQL 、postgres、Redis、Mongo
それらの設定をまとめる
| DB | port | mount | command | ENV |
|---|---|---|---|---|
| MySQL | 3306 | /var/lib/mysql | MYSQL_ROOT_PASSWORD={pass} | |
| postgres | 5432 | //var/lib/postgresql/data | ||
| redis | 6379 | /data | redis-server --appendonly yes | |
| mongo | 27017 | /data/db |
年末～年始の開発 Elixir phoenix、node express、ruby rails 調査
あけましておめでとうございます
年末～年始にかけて、自分で作るゲーム用にサーバ開発の調査をしていた
色々な選択肢があり
C++で作る：経験あるし可能だが、初心者のメンバーがいるので今回は却下
JavaPlayframework：前に作って経験があるし Java8等も使ってみたいが飽きたので
Ruby on Rails、Python、PHP・・： サーバ運用コスト考えると遅いサーバは費用が辛いので却下
Erlang、Haskell、Clojure：趣味に走りすぎか
Scala：ビルド長い
C#：まだMicrosoftロックインははやい
Go：言語的にちょっと・・
で、結局
Rails： ほとんどのフレームワークがRailsライクなので基礎としていつか勉強させるべきだ
Elixir：そこそこ速いらしい。堅牢性は十分。これからのWeb言語の候補
node：そもそもC10Kはnodeが解決すべきであった。言語の堅牢性が悪いが ES6 Babelを使えばかなり回避可能である
の3本に絞った
Rails
一応最初に Railsを調べた。というのは最も日本語情報もありコミュニティが発達していたからだ
あっさりDockerを作り簡単なAPIを作った
一旦中断
Elixir
Alpine Linuxから Elixir環境をビルドしてくるDockerを作ってみた。とりあえず上手くいった
ところが、mixパッケージの依存関係なので、本体バージョンなどの制約があり
色々なバージョンを選べるよう、他人のイメージを使っている
バージョンFixできたらAlphineで1から作りたいところ
現在は、やはりmixパッケージの依存関係で mongodbのライブラリがうまくビルド出来ず
いろんなバージョンを試したり、情報をあさっているところ
正直辛い・・ nodeでいいや という気持ちになってきている
また、最も有名なmongoライブラリ exredisは、findやsave時にエラーか成功かを取れない
という問題もあり redixを使おうと思っている
まだビルドエラーなんだけどね・・
node
ここ数年のJavaScript業界はカオスで情報収集怠っていたが、ふと名案を思い付いた
node+express に対し ES6で記述しBabelすることは必須と思っているが
Webpack等でワンソースにして minifyかけると、実行速度も上がり 素晴らしいはず
そして 通常開発Dockerと ビルド済Dockerを別にすれば Dockerイメージも極小になるし最強ではないかと
方針はなんとなくたった
Builderイメージとrunnerイメージを作り
Builderイメージは 普通に expressで新規プロジェクト作り lebabでES6に変換し開発をする
そして 自動的にBabelしてWebpackしてminifyし Runnerイメージで実行
ただし 色々と躓きポイントがあるので、1個ずつ検証中だ
とりあえず今は普通の Expressでmongodbの設定を試している
データベース指定でconnectすると固まるので 原因をさぐっているところ
あとは オートリロードが出来ていないので不便
そして最大の問題が BuildとRunを別Dockerにして実行させるやつ
ES6対応ともいう
はやくES6使いたい
来年の抱負みたいなもの
来年の抱負みたいなものを
今から来年の事を言うと
あっせんなよ トランキーロ って言われそうだけど一応
仕事について
メインはやはりプログラム。下記で細かく書くけど、ゲームを中心としたのはかわらない
釣りと音楽はそろそろ事業化したい
ゲーム実況的なものを趣味で始める。Youtuberになるとかではなく ライフログ的に
楽しい会社目指したいね
ブログ SNSについて
Facebookは仕事の話題率を高くし、それ以外は極力話さない事にしノイズ減らす
Twitterで仕事以外のつぶやきをし、Twitter率を増やす
はてなブログは基本コードを書くところだが、それ以外も試験的に増やす。現在平均でDailyが25-30 下降気味なので50目指す
C++の記事を増やしたいが当分は色々な技術を書く
Qiitaには はてぶろであるていどまとまってから情報として残す
IT事業
セカンドハウス借りて時々人を呼べる環境は作ったけど、事務所 欲しいね。ちゃんと探そう
ゲームを1本まるっと請け負える体制を1年で作れるかが勝負だ
まずはサーバを〇請けできるよう、サンプルのゲームとサーバインフラ一式の開発を行い営業に使う
Elixirをサーバに使う予定だが、C++技術ももっと勉強する
ゲーム以外はいろいろな新規に誘われているが、C++や人工知能を中心として手伝えれば・・
スタートアップ関連にかんしては どれに集約するか・・だけど 頑張る
インドオフショアも目指す
音楽
セカンドハウスが出来たので、ちゃんと練習する
スラ研、セッパ もっと参加して、Alwaysはミストーンゼロ目指す
その他 アニソンバンド2個もちゃんと練習して再開うながす
大西さんのレッスン受ける体制作る
釣り
セカンドハウスに釣り道具置けるようになった
原付も置けるようになったので、東京湾攻めれる
管釣りでは、普段使ってないルアー練習しパーフェクト目指す
釣り動画作って事業化
釣りゲームも
運動
最近ジム行けてないので毎日行く事にしよう。有酸素無理でもマシンだけでも
とりあえずは1日5キロを目指す。欲いえば1日10キロ1時間
マラソン大会出よう。とりあえずハーフから
Windowsと Bash on WindowsでGolangはじめる
はじめに
以外と困ったのでメモ
まず結果からいえば、現在のGoはWindowsではプラグイン（ダイナミックリンク）が出来ない
ので、出来るだけLinuxで開発しましょう
Windows
インストールは簡単だ
Windowsのばあいはmsiでインストールできるのでそれで問題が無い
バージョンも現在の最新 1.9.2 である
環境変数 GOROOTも設定してくれる（デフォルトで C:\go）
すばらしい！
一応 GOBINに対して、%GOROOT%\bin を設定してみた。
> go get > go build
OK 簡単
Bash on Ubuntu on Windows
$ apt-get install golang
で簡単におわりそうだが、落とし穴がある
$ go version go version go1.2.1 linux/amd64
古すぎる・・・
ので 最新をwgetしてくる
$ apt-get remove golang $ wget https://storage.googleapis.com/golang/go1.9.2.linux-amd64.tar.gz $ tar xvfz go1.9.2.linux-amd64.tar.gz $ sudo mv go /usr/local $ vim ~/.bashrc 環境変数設定 $ source ~/.bashrc $ go version go version go1.9.2 linux/amd64
環境変数は下記のように設定してみた
export GOROOT=/usr/local/go
export GOPATH=/home/yuki/go
export PATH=$GOROOT/bin:$PATH
export GOBIN=$GOROOT/bin
近況：PHP Laravel触ってます
なぜか今までPHPの仕事をしたことがなく
C++やJava等のコンパイル言語ばっかだったし
今更PHP入門ですが、こいつがまた わかりやすい言語でして
表記がCやJavaに似てるから 慣れがある
ただし 何個か気を付けることがある
文字列の連結
+ではなく.
Perlですね
ラムダ、クロージャ
ラムダが使えるんだけど驚くことにC++でいうキャプチャがあるってこと
use() 内にキャプチャする変数を指定
変数
すべて頭に$が必要
メンバ変数やメソッドを呼ぶにも $this->method() とかく必要がある
メンバ変数を参照するときは メンバ変数名の前に$はいらない $this->menber
メンバ変数名を変数で呼ぶことができる。その時は変数名の前にも$をつける
$idx = 'member';
$this->$idx; // $this->idxではなく $this->member が参照される
&
なんとPHPでは参照というのがある
関数の引数や foreachの変数は、コピーなのでそこに対して変更しても反映されないが
&をつけてやると、C++でいう参照となり値を変更することができる
===
JavaScriptなどにあるやつ
===だと型も見て（暗黙型変換をせず）比較してくれる
特に必要なのは null時チェックかな
isset、empty、is_null
細かい違いはおいておいて、コンパイル言語とは違い未定義という状態もあり得る
その時に falseを返したりする
ただしラムダのキャプチャ(use)なり、関数の引数にするときは Undefinedエラーが出るので定義しておかないとだめ
可変長引数も使えるけど・・・ねぇ・・・
Array
ちょいめんどう
配列はない。全部連想配列である
省略すると intのKey 自動インクリメントで保存されるので実質配列のように扱うことができるが
stringのKeyと同居することも出来る
また 初期化及び値を代入する際も hoge( 'key' => 'value') のように書く
ここは 慣れるしかない
Laravel
Railsライクなライブラリなので、なんとなーくRailsを知ってれば扱いやすいんじゃないかな？
Railsとの比較はほかの人に任せます。私は比較できるほどの知識はない
総括
Dev-Ops
なんとなく 調べながらメモをかく 駄文
Dev-Opsとは
Dev: デベロッパー。つまりプログラマなどの開発者
Ops: オペレータ。つまり運用
昔から両者は立場、考え方が違い衝突をしていた
開発者は、新機能の実装を早くリリースしたいが
運用者は、不具合の可能性のある新機能には慎重で既存の不具合修正を優先してほしい
開発者は、不具合の修正や新機能の1タスクが終わるたびにリリースしてほしいが
運用者は、バージョン管理や運用ミスを考え、数週間まとめてリリースしたい
不具合が発生した場合
開発者は運用のミスを疑い
運用者は開発のミスを疑う
開発者はオペレーターマニュアルを書き、運用はその通りに実行する
など、昔から色々と問題があった
一見いがみ合っているようだが、立場が違うだけで目的は同じ
ユーザーに喜んで使ってもらいたい。サービスを良くしたい
目的が同じなら、仲良くなれるはずだ
https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
インフラ構築の自動化
昔は、インストールマニュアルというものがあり、その手順通りインストールしていた
当然 インストールの工数や人為的ミスがおこる
Chef、Puppet、Ansible、Docker など
バージョン管理システム共有
運用がソース管理システムを使わず、開発がビルドしたファイルのみを扱っていた時代もある
今では運用もGitなどを見て、コミットメッセージを見たり、任意のバージョンでビルドして確かめたり
コードレビューに参加したりすることも当たり前になってきている
Gitなど
ワンステップデプロイ
過去においては、手順書をみてサーバへのデプロイを手動で行っていた
当然 工数と人為的ミスが増える
現在では Jenkins、Capistrano
フューチャーフラグ
新機能、特別なイベントなどを設定ファイルでON/OFFする
新機能のデプロイを 設定ファイルの変更のみで出来る
メトリクス
過去においては開発者はあまり サーバー負荷の数値などに関心がなかった
運用が行う仕事だと思っていたからだ
運用がメトリクスを見て、サーバ負荷の問題を開発に報告してから調べはじめる
だが、今の時代は常に開発者もメトリクスを見て一刻も早く気付くべきだ
NewRelic、ApplicationInsights 等
チャット＆チャットBOT
Slack、HipChat等のツールを使い
デプロイ、アラートのログを共有したり
自動化できるところは自動化していきたい
そしてその後は精神論
リスペクト
ステレオタイプで考えるな（プログラマがみんなルーズじゃない）
他人の経験や意見を尊敬する
NOとだけ言わない
隠さない
信頼
OpsはDevの機能追加を信用し、DevはOpsのインフラ変更を信用する なｄ
失敗にたいして健全に
失敗は誰しもがおこす。ミスを責めない
非難を避ける
失敗を責めない
同じ失敗がおこらないよう、建設的な考えをすべき
まとめ
過去においては DevとOpsは立場が違い対立することもあった
そのこと自体は、お互いにけん制しあいミスを防ぐのに役立ってた面があるかもしれないが
今の流行りは、DevとOpsが仲良く協力的になる事
Opsはソース管理を使ったり、コードレビューを行ったり、過去のバージョンを自分でビルドし調査したり
もっと Devに歩み寄る
Devはメトリック等を自分たちも関心をもち、Opsに歩み寄る
自動化できる部分は積極的に自動化し、工数と人為的なミスを減らす
よく使われるツールとしては
構成ツール：Docker、Chef、Vagrant、Ansible、Puppet・・・
ソース管理：Git（Github、Gitlab）
CI：Jenkins、CirculerCI
チャット：Slack、HipChat
メトリクス：NewRelic、ApplicationInsights
そして 人間間の リスペクト、信頼、非難しないなどがとても重要
それに加え、リーン性、計測なども重要視されている
DevとOpsは仲良くなる。むしろ 仕事や立場がオーバーラップする
時代の流れはそうなっているようだ
Docker修行中
はじめに
とりあえず、勉強中の殴り書きをすることに
Dockerとは
コンテナ仮想技術と言われている
例えば、クラウドであれば物理的に異なるハードウェア＆OSに対してTCP等で接続するもの
VirtualMacheneは物理的に同じハードウェア上に異なるOSを動かす
Dockerはコンテナとしてそれぞれのサービスを立ち上げる
VMと何が違うかを説明するのがまだ難しいんだけど
VMはゲストOSをインストールしその中にすべてのサービスをインストールするが
Dockerは サービス単位でコンテナを作り起動する
とりあえず、Dockerのほうが軽いと思っていいかな
ではなぜDockerを使うかというと
今までの開発では、ローカルに環境を作って開発をしていた
新人が入れば環境構築マニュアルを見てセットアップ行い、たいてい失敗して数日かかる
特に WindowsだけでなくMacで開発することも多い
それらの環境構築を、仮想コンテナで環境を整えるので、セットアップが速い
Dockerの種類
Dockerは基本的に Linuxカーネルでしか動かない
そのため、WindowsでもMacでも まずは VMの上にLinuxを動かし、そのうえでDockerを動かす必要がある
ところが Windows10 Pro 64bitでは、Hyper-V上に直接Dockerを動かす事が出来る
マジすばらしい！
ところが WindowsではBashが動かないため、Macや DockerWindowsが動かないWindowsでも開発する場合
シェルスクリプト対策をする必要がある
Bash on Windowsは便利だが、こちらもHyper-Vで動いているため、ホストのDockerを直接見ることが出来ない
そのため Bash on Windows上にDockerをインストールし、向き先をホスト上に変更したりすれば多分行けると思う
あるいは Window用に バッチファイルやPowerShellも作るなど
Docker概要
まずDockerには イメージ、コンテナ、ボリュームがある
イメージはコンテナのイメージファイルとなっている
コンテナはイメージを起動した際に作成され、イメージの一次的な情報を持っている
ボリュームは、データベースの中身など永続的に持っておきたいデータ
docker ps
docker images
docker volume ls
でそれぞれ リスト表示
docker pull イメージ名
で、イメージを DockerPubより落として来る
docker run -it イメージ名
でイメージからコンテナを起動
docker start イメージ名
で停止したコンテナを再開する
Ctrp+P、Q でコンテナを起動したままホストに戻る
exitで抜けた場合はコンテナは停止する
docker exec -it コンテナ名 /bin/bash
等で 起動中のコンテナにログインする
docker commit コンテナ名 イメージ名
で、コンテナからイメージを作成する
また、コンテナを立ち上げる際に、ボリュームやポートフォワードを指定する
Build
上記のように コンテナ内で環境を構築し commitでイメージに焼き付けてイメージを配布してもよいが
インストール手順ファイルを作成し、そこからイメージを作成するほうが便利である
まずはDockerfileを作成する。ここにはインストール手順を書く（Chefのようなもの）
Dockerfileを書いた後に buildコマンドを使いイメージを作成する
docker build -t イメージ名:タグ名 .
で作成できる
Dockerfileの書式は後程？
docker-compose
Dockerは通常複数のコンテナを組み合わせて使う
たとえば アプリケーション、RDB、NoSQL、バッチ・・・
と複数のコンテナを立ち上げる必要がある
この際に、全部を手作業で立ち上げるのも大変だし、それぞれボリュームやポートフォワードオプションも設定する必要がある
もちろん シェルスクリプトで全部書けば簡単だが、docker-composeを使えば簡単になる
docker-composeを使えば、複数のコンテナを順番に起動することが出来る。ボリュームやポートフォワード、ホスト名の設定等ができる
docker-compose build で、全てのコンテナイメージ作成
docker-compose up ですべてのコンテナを立ち上げる
docker-compose down で すべてのコンテナを落とす
docker-compose run 名前 で 1つのコンテナを立ち上げる
その他いろいろと便利
