/var/log/study

つまり雑記

webサーバー開発週報 第3週目

github.com

進捗

  • httpサーバーとしての新機能は無し
  • httpサーバーとしての機能修正も無し
  • 細々とした修正をした
    • virtual host を設定できるようにすることを見越して

今週の詰まりどころ

  • 進捗が少ないのでなし
  • グローバル変数的なものの扱いをどうするのか、未だによくわかってない
    • ググったらそれっぽいのは出てくるけど、試せてない

感想

  • 今週は新しい進展が無かった
    • 仕事の負荷が若干上がってきた
    • 仕事で使いたいコードを書いていた
  • 来週はもう少し時間を取りたい

webサーバー開発週報 第2週目

前回

yaaamaaaguuu.hatenablog.com

まぁ1週間は続くよね。

進捗

  • 相変わらずstaticなwebサーバー
  • 追加系
    • HEADリクエストに対応した
    • Content-Encodingヘッダーを追加した
    • Last-Modifiedヘッダーを追加した
    • JSONの設定ファイルでallow_hostとportを指定できるようにした
  • 変更系
    • レスポンスの内容がある際はgzipで圧縮するようにした
    • いくつかのメソッドにテストコードを足した
      • HSpec
    • http-dateのフォーマットを多分RFC 1123に準拠させた
  • やりたかったけどできなかった
    • 設定ファイルをhclにできなかった
    • ドキュメントルートも指定できるようにしたかったが未着手

今週の詰まりどころ

  • 型が面倒
    • StringとかByteStringとか, IntとかInt64とか
      • gzipで圧縮することより、内部的な型の方が厄介だった
    • どこかの場面でとても大切なのかもしれないけれど、今のところそこら辺はよしなにやってほしい気持ちの方が大きい
  • 設定ファイルをhclにしたかった
    • Hashicorpのやつ
    • ライブラリはあるけどJSON互換の運用ができるやつでは無かった為に使いかたがパッとはわからなかった
    • というかそもそもJSONのパースも若干面倒

感想

http1.0対応の根幹は結構できてきたと思う。がhaskellっぽいコードか?と問われるとかなり微妙。

そもそも、すごいHaskellとかを挫折してこういう取り組みを行っているので、haskellっぽいコードにならないのは仕方が無いと割り切るしか無い。

HSpecはかなり好きだが、webサーバーとしてテストが網羅できてるかはコレまた怪しい。

そろそろhttp1.0のstaticなwebサーバーは脱却して、少しずつcgiとかに対応できたら良いなぁと思う。

webサーバー開発週報

webサーバー開発週報 第1週目

続くかどうかはよくわからないけど、どうせやるなら週報とかつけてみるとモチベーションが上がるのではないかなぁ?と思って書いてみる。

  • haskellでwebサーバーの実装を始めた
  • 自分が実装したいものを気ままに実装していく方針

リポジトリは以下

github.com

進捗

  • 現状レスポンスは固定
    • 正常のときは200
    • 正しくファイルが開けないとき or ファイルが無い時は404を出す
    • ヘッダーは以下を付与
      • Server
      • Accept-Ranges
      • Content-Type
      • Content-Length
      • Date
  • 以下のファイルをレスポンス出来るようになった
    • html
    • css
    • js
    • png
    • jpg
    • たぶんgig

今週の詰まりどころ

  • imageが上手くレスポンスできずに詰まった
    • pngとかjpgとかgifとか
    • しばらくは Network.Socket を利用していたが、 Network.Socket.ByteString があることに気がついた
    • Network.Socket だとテキストはさくっと返せるが、バイナリなデータはいい感じに返せない?
    • 上記のライブラリのどちらでも、send 関数を一度読んだだけでは送りたいデータを送りきれない事にも気づくのに時間が掛かった。

GitLab CI Runner をProxy環境下で動かす

前提

とあるネットワークのセグメント配下に設置されたVM -> GitLabへの通信はProxyを通す必要があり、かつそのVMがGitLab CI Runnerの役割を果たしている時の話し

準備

docs.gitlab.com

上記のページに沿ってci runnerをインストールしたらOK

ハマりどころ

インストール後はci runnerをgitlabに登録することになる。ただしProxyの設定をしておかないと登録はできるがGitLabからCIをキックできずにハマる。

なのでその次のステップの登録はちょっとまって欲しい。

Proxyの設定

gitlab.com

上記のissueのコメントの Adding Proxy variables to the runner config, so it get's builds assigned from the gitlab behind the proxy に書いてあるとおり、 /etc/systemd/system/gitlab-runner.service.d/http-proxy.conf などを作って、systemd側からproxyの設定をgitlab ci runnerに渡してあげる必要がある

Proxyの設定を登録したら 

docs.gitlab.com

上記の通り、gitlab ci runnerを登録したら良い

与太話

自分がgitlab ci runnerをproxy配下で動かそうと試行錯誤している途中で、gitlabのデータがおかしくなって、gitlab ci runnerがweb uiから登録解除というか削除できなくなってしまった。

そのような場面に陥ったら以下のissueを参考にすると良い。CLI側からもci runnerを登録解除できる。登録解除に必要なTokenなどは /etc/gitlab-ci-multi-runner/config.toml を参照したら見つけられるはず。

gitlab.com

PHP, Python, Golang を NGINX Unit で動かしてみた

NGINX Unit

ホームページは以下

www.nginx.com

もしくはミラーだけどGitHubが以下となる

github.com

RestAPIやJSONで設定できる、phpPHP-FPMやpythonwsgiサーバーなど言語ごとのアプリケーション・サーバーを集約したアプリケーションサーバーという感じ。なのでNginxの後ろで動くサーバーという認識で大丈夫なのかな?

まだversionは0.1なので、今後どんどん成長していくはず。

現状は以下に対応しているとのこと

Python 2.6, 2.7, 3

PHP 5, 7

Go 1.6 or later

ざっくりとした所感

  • プロダクトに関して
    • 言語ごとのミドルウェア運用がNGINX Unitに集約されて嬉しい可能性がある
    • Docker + NGINX Unit も嬉しいが、NGINX Unitだけでも十分に嬉しいかも
    • ベンチマークを取ってどれだけさばけるか試したい
  • 現状のドキュメントに関して
    • インストールはドキュメントどおり行えばOK
    • アプリケーション・サーバーとしての動作
      • PHPはさっくりと動かせた
      • Pythonもちょっとwsgiに関して少し調べれば動かせた。
      • Golangissue を見つけなかったら動かせなかったと思う
    • まだ細かいチューニング方法とかもドキュメントには記述されていなさそう?

と、言うことで、3つの言語で動かした際の動かし方を残しておく (最初にドキュメントを読んで、詰まった際の補助資料くらいに思うと良いはずです。)

動かし方

インストール後のサービスの動かし方

systemctl enable unitd.service
systemctl start unitd.service

気づき

  1. curl --unix-socket /run/control.unit.sock http://localhost/ で設定を確認できる.
  2. systemctl restart unitd.service をしたら設定が揮発する模様?

各言語ごとの動かし方をまとめ

要点だけ

PHP

設定で指定する rootindex で指定するファイルを置くだけ

Python

設定で指定するpathwsgi.py を設置, wsgi.py の中で applicationwsgiアプリケーションになっていればOK

例えばFlaskなら以下の様な感じ

#!/usr/bin/env python

from flask import Flask

application = Flask(__name__)

@application.route("/")
def index():
    return "<h1>Hello NGINX Unit</h1>"

Golang

こっちが一筋縄では行かなかった。

まず、unit をインストールしているだけではダメでCentOSでは unit-devel をインストールしておく必要があることと、

export GOPATH=/home/user/go_apps をしておいた後に、 unit パッケージをインポートして使う。

上記の状態で、以下のようなソースをビルドし、設定の executable で指定したパスに配置する。

package main

import (
    "fmt"
    "net/http"
    "unit"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "<h1>Hello NGINX Unit</h1>")
    })
    unit.ListenAndServe(":8000", nil)
}

普通のgolangのアプリと違うのは、 ListenAndServe するのが、httpではなく unit な点だと思う

個人的感想

NGINXが新しくサーバーをリリースする!というのは個人的に驚き。

ApacheよりもNGINXに慣れ親しんでいる世代ということもあり、頑張ればソースコードを読み切る事ができそうな気がする規模なので読みたい。

以下は全部この記事を書いた際のメモ

とりあえず動かしてみる

CentOS7でやってみる

[root@mycentos7 go-app]# cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)

↑のインストールにそって yum -y install unit で問題なくうまくいく

ドキュメント的にはインストールで終わっているので動かし方を探ると以下の感じで動き出す。定石どおり。

[root@mycentos7 unit]# systemctl status unitd
● unitd.service - NGINX Unit
   Loaded: loaded (/usr/lib/systemd/system/unitd.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
systemctl enable unitd
systemctl start unitd
[root@mycentos7 unit]# systemctl status unitd
● unitd.service - NGINX Unit
   Loaded: loaded (/usr/lib/systemd/system/unitd.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2017-09-08 00:42:25 JST; 6s ago
  Process: 2502 ExecStart=/usr/sbin/unitd $UNITD_OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 2503 (unitd)
   CGroup: /system.slice/unitd.service
           ├─2503 unit: main [/usr/sbin/unitd --log /var/log/unitd.log --pid /run/unitd.pid]
           ├─2505 unit: controller
           └─2506 unit: router

プロセスとしては動いていそう。

[root@mycentos7 unit]# ps aux | grep unitd
root      2503  0.0  0.0  16168   632 ?        Ss   00:42   0:00 unit: main [/usr/sbin/unitd --log /var/log/unitd.log --pid /run/unitd.pid]
root      2516  0.0  0.0 112644   964 pts/0    R+   00:44   0:00 grep --color=auto unitd

lsofを叩いてもunitdが掴んでいるポートはなさそう?

[root@mycentos7 log]# lsof -i
COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
chronyd   715 chrony    1u  IPv4  13918      0t0  UDP localhost:323
chronyd   715 chrony    2u  IPv6  13919      0t0  UDP localhost:323
sshd     1038   root    3u  IPv4  16617      0t0  TCP *:ssh (LISTEN)
sshd     1038   root    4u  IPv6  16626      0t0  TCP *:ssh (LISTEN)
master   1648   root   13u  IPv4  17586      0t0  TCP localhost:smtp (LISTEN)
master   1648   root   14u  IPv6  17587      0t0  TCP localhost:smtp (LISTEN)
dhclient 2260   root    6u  IPv4  18318      0t0  UDP *:bootpc
dhclient 2260   root   20u  IPv4  18307      0t0  UDP *:46788
dhclient 2260   root   21u  IPv6  18308      0t0  UDP *:gilatskysurfer
sshd     2339   root    3u  IPv4  19514      0t0  TCP 172-0-1-5.lightspeed.brhmal.sbcglobal.net:ssh->192.168.1.5:64437 (ESTABLISHED)

ドキュメントを読むと

By default, the Unit API is available in the control socket file unit.control.sock.

と書いてあるので、探すと /run/control.unit.sock があることがわかった。

[root@mycentos7 log]# find / -name 'control.unit.sock'
/run/control.unit.sock

ミニマルと呼ばれている設定を投げつけることにする

ドキュメントどおり以下の設定ファイルを

{
  "listeners": {
    "*:8300": {
      "application": "blogs"
    }
  },
  "applications": {
    "blogs": {
      "type": "php",
      "workers": 20,
      "root": "/www/blogs/scripts",
      "index": "index.php"
    }
  }
}

curl -X PUT -d @./start.json --unix-socket /run/control.unit.sock http://localhost/ で投げつける

レスポンスは以下の様

{
    "success": "Reconfiguration done."
}

ではphpを設置してみる。

[root@mycentos7 ~]# mkdir -p /www/blogs/scripts
[root@mycentos7 ~]# touch /www/blogs/scripts/index.php
[root@mycentos7 ~]# echo -e "<?php\n\nphpinfo();" > /www/blogs/scripts/index.php
[root@mycentos7 ~]# cat /www/blogs/scripts/index.php
<?php

phpinfo();

curl localhost:8300 できちんと反応する

自分のホストのIPだと反応がないと思ったが、firewalldを切ったらきちんと反応した.

ちなみにドキュメントの何処かに書いて有りそうだが、 curl --unix-socket /run/control.unit.sock http://localhost/ で設定を確認できる.

また systemctl restart unitd.service をしたら設定が揮発した。たぶんココらへんは今後改良される点なはず。

Python

こうなったらpythonもためしたい。

またしてもドキュメントどおりの設定を投げつけ、

{
  "applications": {
    "blogs": {
      "type": "php",
      "user": "nobody",
      "group": "nobody",
      "workers": 20,
      "root": "/www/blogs/scripts",
      "index": "index.php"
    },
    "wiki": {
      "type": "python",
      "user": "nobody",
      "group": "nobody",
      "workers": 10,
      "path": "/www/wiki",
      "module": "wsgi"
    }
  },
  "listeners": {
    "*:8300": {
      "application": "blogs"
    },
    "*:8400": {
      "application": "wiki"
    }
  }
}

/www/wiki/wsgi.py を以下のように作る

[root@mycentos7 wiki]# cat wsgi.py
#!/usr/bin/env python

from flask import Flask

application = Flask(__name__)

@application.route("/")
def index():
    return "<h1>Hello NGINX Unit</h1>"

こちらもそつなく動く

golang

ついでだからgolangも書いておく。今度はドキュメントからチョット変更して以下のような設定を投げつける

{
  "applications": {
    "blogs": {
      "type": "php",
      "user": "nobody",
      "group": "nobody",
      "workers": 20,
      "root": "/www/blogs/scripts",
      "index": "index.php"
    },
    "wiki": {
      "type": "python",
      "user": "nobody",
      "group": "nobody",
      "workers": 10,
      "path": "/www/wiki",
      "module": "wsgi"
    },
    "go_server": {
      "type": "go",
      "executable": "/www/server/bin/server",
      "user": "nobody",
      "group": "nobody"
     }
  },
  "listeners": {
    "*:8300": {
      "application": "blogs"
    },
    "*:8400": {
      "application": "wiki"
    },
    "*:8500": {
      "application": "go_server"
    }
  }
}

でもって以下のようなコードを作って… と思ったら、golangは普通にnet/httpを使うのではダメな模様

https://github.com/nginx/unit/issues/8/ に書いてある/usr/share/doc/unit/examples/go-app/let-my-people.goを覗くと unit というパッケージがある

package main

import (
    "fmt"
    "net/http"
    "unit"
)

func handler(w http.ResponseWriter, r *http.Request) {
    w.Header().Add("Content-Type", "text/plain");

    fmt.Fprintf(w, "Method : %s\n", r.Method)
    fmt.Fprintf(w, "URL    : %s\n", r.URL.Path)
    fmt.Fprintf(w, "Host   : %s\n", r.Host)
}

func main() {
    http.HandleFunc("/", handler)
    unit.ListenAndServe("8000", nil)
}

上記をissue真似て, sudo yum -y install unit-devel をしたあとexport GOPATH=/home/user/go_apps, 以下のファイルを go build して /www/server/bin/server としてファイルを設置したら curl localhost:8500が上手くいった.

package main

import (
    "fmt"
    "net/http"
    "unit"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "<h1>Hello NGINX Unit</h1>")
    })
    unit.ListenAndServe(":8000", nil)
}

以上でPHP, Python, GolangでUnitを動かしてみる事自体は完了となる

備忘録 自宅リージョン 2017/08/26

yaaamaaaguuu.hatenablog.com

yaaamaaaguuu.hatenablog.com

↑の記事から半年の間に色々と試した結果、自宅の構成が固まってきたので備忘録を書こうと思った。

vSphere環境を自由に使える状態になったので、ミドルウェアの使いかたの学習やちょっとしたアプリ開発VMがほしいときにクラウドサービスを使う必要が無くなった。

(ちなみにvSphereとかはライセンスの問題で定期的に入れ替えて使っている)

機材

半年前から買い足した機材は2台

Ubiquiti Networks Edgerouter ER-X(日本国内)

Ubiquiti Networks Edgerouter ER-X(日本国内)

VyOSとかを触る機会を作りたいなぁと思っているところでEdgerouterを知った。

NASはvSphere環境でvmotionしたくて買った。自宅でもvMotionできると何かと便利な気がする。最近Synologyが良いと聴くけど基本的に機材の良し悪しはよくわからない事と、switchや以前から使っている無線ルーターがNETGEARなのでNASもNETGEARにした。

あと本当はNUCを1台買い足しているけれど、メモリが高騰していて買えていないので投入できていない

現状のネットワーク図

学習用途を兼ねているし、ネットワークの設計や仮想化環境の扱いはほぼ素人なので、その手の人から見たら無駄や設計ミスがあると思う。

基本的にはhomeのセグメントに接続しているmacからmyprivateのセグメントに置いたVMsshで繋いで検証とかを行っている。Edgerouterとvyosでルーティングしている

f:id:yaaamaaaguuu:20170826171333p:plain

  • 共通
    • 各セグメント共にEdgerouterがDHCP + DNS + NTPのサーバーの役割を果たしている
  • homeのセグメント
    • 今まで通り家庭用のネットワークとして使う
    • laptopとかスマホとかをwifi経由で接続する
  • managementのセグメント
    • 有線でつなぐためにあけてある
    • 冷静に考えて無駄な気がしている
  • mycloudのセグメント
    • 実際はswitchにぶら下がっている
    • 物理ホストやNAS, vCenterサーバーなどを置く所
  • myprivateのセグメント
    • 適当にVLANを切っている
    • 検証用のVMを置く所

反省と今後

vSphereの仕様上、VMの足を生やす上限は10個までとなっているので、検証で切りたいセグメントが10を超えたらリソース消費との兼ね合いでvyosをチョットずつ継ぎ足していくのかな?とか考えている。

この環境を作る途中、困ったタイミングで適当にVMKernelを作ったりしたのでipの払い出しがいい加減な所がちょこちょこある。もっとvSpereの仕様とかを把握したほうが良いはず。

またこの環境は基本冗長構成が取られてないし、各機器の監視なども特にしていないのでチョットずつ育てていこうかな?と言う気持ちになっている。

git remote がhttpsでbasic認証している時の自動化方法

前提となる話

gitのリモートには git://https:// が使える。要はsshhttpsかという違いで、諸事情によりsshを利用せずhttpsを使いたい場面がある。

sshならばパスフレーズのないdeploy keyなどを用意したら、あとはキーの取り回しをどうしたら良いか?で事が済むが、httpsかつ認証が必要なリモートリポジトリを扱う際はパスワードを入力する必要が出て来る。

httpsを利用した際の認証はbasic認証なので、 git clone をする際に認証情報を埋めたら自動化できるのだが、git remote -v で認証情報が丸見えとなる。(と言うか、自分の作った環境を先輩に見せたら丸見えの状態で非常に恥ずかしかった) ので、以下のURLで示されている方法は得策ではない。

stackoverflow.com

.netrc を利用するといちいちパスワードを入力する必要も無い。しかし通常は平文、チョット気を使うと暗号化できたりするが、何れにせよユーザーとパスワードを保存した状態となるので、様々な人が触るサーバーで .netrc を使うのは得策と言えないだろう。

加えてスクリプトから扱う専用のユーザーをリモートリポジトリのサーバーに作りたくない。リモートリポジトリ側のユーザー管理が雑になる可能性があるので、極力普段使っているユーザーの認証情報で済ませたい。

ではansibleやjenkinsなどの自動化ツールを使った際に認証付きhttpsリポジトリを扱うのはどうしたら良いか?という点に話を移すと、対話が必要なときは expect コマンドなどで頑張るのが回答の候補に上がるだろう。個人的には expect とか泥臭すぎると思うのでその方法は避けたい。

ということで今回は以下の前提で話を進める

  1. httpsかつ認証付きのリモートリポジトリ
  2. 様々な人が触る環境なので、ユーザーに紐づく状態を作りたくないという
  3. 自動化用のユーザーは作らない
  4. expectは使わない

git credential helper

環境変数経由で渡せるとansibleとかjenkinsで簡単に自動化ができるなぁと思いながら、gitを調べていたら credential helper なるものが有るのを発見した。

Git - 認証情報の保存

使いかたとか設定方法は大体上記に書いてある。

git config --global credential.helper cache

と設定すると、ファイルには設定を保存せず、ある程度の時間認証情報を保持してくれるようになるとのこと。

加えて以下を実行すると認証情報が渡せるとのこと。

git credential fill

惜しい。なにが惜しいか?というと、さらっと調べる限り、標準入力等では git credential fill に情報を渡すことはできなさそう?だった。

自動化方法

Git - 認証情報の保存 には 独自の認証情報キャッシュ という項目がある。

サクッと読むと git hook と同じように、独自コマンドを利用することが可能らしい。サンプルに乗っているRubyをパクって、環境変数を渡すようにしたら良さげ。

ということで、以下のようなスクリプトを実行権限付きで、 /usr/local/bin/git-credential-env とかで設置し、 git config --global credential.helper env とかすると、環境変数経由で認証情報を渡せるようになる。

gist.github.com

あとは、ansibleのenvironmentやjenkinsのパラメーター付きビルドで GIT_PROTOCOL, GIT_REMOTE_HOST, GIT_USER, GIT_PASSWORD を指定してやるといい感じに自動化できる。

スクリプトデバッグは以下で。

GIT_PROTOCOL=https GIT_REMOTE_HOST=github.com GIT_USER=hoge GIT_PASSWORD=fuga ./git-credential-env.sh get
protocol=https
host=github.com
username=hoge
password=fuga

注意点

  • スクリプトshebangは環境によって適度に変えてください。
  • 環境によってはcredential.helperを既に設定している可能性があるので、むやみに上書きしないように。