/var/log/study

つまり雑記

iron functions の web uiを試す

CoreOS Docker iron functions

yaaamaaaguuu.hatenablog.com

上記の続き

iron functions の web ui はきちんと開発されているよう

github.com

動かしてみる

core@coreos004 ~ $ ip a
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:50:56:ad:ce:53 brd ff:ff:ff:ff:ff:ff
    inet 172.0.1.36/24 brd 172.0.1.255 scope global dynamic ens192
       valid_lft 70170sec preferred_lft 70170sec
    inet6 fe80::250:56ff:fead:ce53/64 scope link
       valid_lft forever preferred_lft forever
core@coreos004 ~/iron_functions $ pwd
/home/core/iron_functions
# iron function を動かす
core@coreos004 ~/iron_functions $ docker run --rm -it --name functions -v ${PWD}/data:/app/data -v /var/run/docker.sock:/var/run/docker.sock -p 8080:8080 iron/functions
# iron function の ui を動かす
core@coreos004 ~ $ docker run --rm -it --link functions:api -p 4000:4000 -e "API_URL=http://172.0.1.36:8080" iron/functions-ui

こんな感じで docker run さえ行えば簡単に動き出す。 本当はdocker-composeなどにまとめたほうが良いのかもしれないが。

f:id:yaaamaaaguuu:20180225011931p:plain

UIから出来ることは以下。

  • プロジェクトを作る
  • プロジェクト配下のルーティングとキックするコンテナを指定する
    • 当然ルーティングの編集、削除も出来る
  • 指定したルーティングのキックをする
  • IronFunctionsのSwaggerに飛べる

UIを眺めていて、特にルーティングとキックするイメージの指定の際は、結構細かいことを指定可能な事が認識できた。 タイムアウトとか並列度とかは後日試そうと思う。

プロジェクト内のスクショ

f:id:yaaamaaaguuu:20180225012510p:plain

新しいルーティングのスクショ

f:id:yaaamaaaguuu:20180225012543p:plain

ルーティングを走らせるUIのスクショ

f:id:yaaamaaaguuu:20180225012637p:plain

iron functions を試す

Docker CoreOS iron functions

世の中がサーバーレスアーキテクチャ！と言い出して数年たった。個人的な感想としてlambdaのイベントからキックされるモデルはとても良いと思う反面、APIゲートウェイとlambdaを組み合わせるアーキテクチャは負けだなぁと感じている。

話は変わるが、エンジニアのレイヤ的にもプログラミング言語的にも多様性がある環境では、「バッチなどの処理は問題ないがAPIに仕立てるのは...」 という場面に出くわすようになる。バッチ処理をコンテナ化したらAPIサーバーに仕立ててくれるOSSが無いかなぁ？などと思って見つけたのが iron function というサーバーである。

負けだなぁと思っていたアーキテクチャも、立場と捉え方が変わると欲しかったものに変わるもんだなぁと言うことも学べた。

とりあえず今日のブログは、モチベーションが下がらないうちにチュートリアルまで。後日、CLIツールやWeb UIなども検証してブログにするつもり

Iron.io Open Source - Functions

iron functions とは?

とあるURLに対して、実行するコンテナを登録できる、AWS API Gateway と lambda を組み合わせたようなサーバー

雑に特徴を書き下すと以下のような感じ

  • API
    • プロジェクトの作成ができる
    • プロジェクト配下のパスに、キックするDockerコンテナを登録する
    • http://${IP}:${PORT}/r/${PROJECT_NAME}/${REGISTER_PATH}
    • 登録されたパスで、Dockerコンテナをキックできる
    • キックされたDockerコンテナの標準出力がAPIのレスポンスになる
  • 利用可能なコンテナ
    • dockerhubに公開されいてるもの
    • きちんと立てたプライベートレジストリ
      • http認証しか無いinsecureなPrivateのコンテナレジストリを利用するのは現状無理そう
  • 構築
    • Docker run するだけ
  • その他
    • CLIがある
    • Web UIがある

基本的な検証

利用環境はvSphere環境上に立てたCoreOSの上

core@coreos004 ~ $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:50:56:ad:ce:53 brd ff:ff:ff:ff:ff:ff
    inet 172.0.1.36/24 brd 172.0.1.255 scope global dynamic ens192
       valid_lft 86276sec preferred_lft 86276sec
    inet6 fe80::250:56ff:fead:ce53/64 scope link 
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:d4:7f:04:bd brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 scope global docker0
       valid_lft forever preferred_lft forever
core@coreos004 ~ $ cat /etc/os-release 
NAME="Container Linux by CoreOS"
ID=coreos
VERSION=1632.3.0
VERSION_ID=1632.3.0
BUILD_ID=2018-02-14-0338
PRETTY_NAME="Container Linux by CoreOS 1632.3.0 (Ladybug)"
ANSI_COLOR="38;5;75"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://issues.coreos.com"
COREOS_BOARD="amd64-usr"
core@coreos004 ~ $ docker version
Client:
 Version:      17.09.1-ce
 API version:  1.32
 Go version:   go1.8.5
 Git commit:   19e2cf6
 Built:        Thu Dec  7 22:19:00 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.09.1-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.5
 Git commit:   19e2cf6
 Built:        Thu Dec  7 22:19:00 2017
 OS/Arch:      linux/amd64
 Experimental: false

構築

適当にディレクトリをほって、docker run するだけ

core@coreos004 ~/iron_functions $ pwd
/home/core/iron_functions
core@coreos004 ~/iron_functions $ docker run --rm -it --name functions -v ${PWD}/data:/app/data -v /var/run/docker.sock:/var/run/docker.sock -p 8080:8080 iron/functions

動作チェックは手元のPCから以下のコマンド

⋊> ~ curl http://172.0.1.36:8080
{"goto":"https://github.com/iron-io/functions","hello":"world!"}

チュートリアル的な

プロジェクト作成 -> パスとコンテナの登録 -> 実行

プロジェクト名はmyapp, パスはhello, 実行するコンテナはiron/hello となっており、最終的には http://172.0.1.36:8080/r/myapp/hello でAPIが叩けるようになる

まずプロジェクトの作成を手元のPCからcurlで実行

#コマンド
curl -H "Content-Type: application/json" -X POST -d '{"app": { "name":"myapp" }}' http://172.0.1.36:8080/v1/apps
#レスポンス
{"message":"App successfully created","app":{"name":"myapp","config":null}}

パスの登録も手元のPCからcurlで実行

#コマンド
curl -H "Content-Type: application/json" -X POST -d '{
         "route": {
             "path":"/hello",
             "image":"iron/hello"
         }
     }' http://172.0.1.36:8080/v1/apps/myapp/routes
# レスポンス
{"message":"Route successfully created","route":{"app_name":"myapp","path":"/hello","image":"iron/hello","memory":128,"headers":{},"type":"sync","format":"default","max_concurrency":1,"timeout":30,"idle_timeout":0,"config":{},"jwt_key":""}}

コンテナの動作チェック。ちなみに初回実行時はコンテナのpullで多少時間がかかる

curl http://172.0.1.36:8080/r/myapp/hello

出力

Hello World!

まとめ

とりあえず、コンテナを登録して実行するところまでは速攻で終わった。めちゃ簡単。

前述のとおり、明日にでもWebUIとCLIを試した記事を挙げるつもり。

VMware環境でContainerLinux (CoreOS) の基本的プロビジョニングの仕方

CoreOS Docker

ものすごい今更感のあるネタだけれども、世の中に出回っている情報が？？？という気持ちがしたので書いておく。

ESXiにCoreOSをインストールするには？みたいなことを調べる、以下の様な情報が出て来る。

VMware Knowledge Base

上記は2015年の記事で、おそらく現在は当時と事情が異なる。（はず。）

大前提

  • OVAをデプロイしようとすると最後にカスタマイズのウィザードが出て来る
    • そこでcloud-configを指定してあげたら終了
  • 学習目的であればKBの通り一旦オートログインでcloud-configを作るほうが便利
  • つまり動くcloud-configがあれば、auto-loginなぞ有効にしなくても良いということ。

実際に出てくるウィザード

f:id:yaaamaaaguuu:20180211203317p:plain

こんなに丁寧に、cloud-configのURLは？と聞かれているので、適当なファイルサーバーを作ってそこからダウンロードするようにしたら良い。

もしくは、その２段上のInline cloud-config を使っても良いかもしれない。が、Inlineの方は、改行が微妙な事になっているので自分では検証していない。

EdgeRouter X を Prometheus の node_exporter でメトリクス収集をしてみる

EdgeRouter Prometheus Docker

世の中にzabbixとMackerelは実際の知見があったけど、Prometheusを利用してEdgeRouterのメトリクス収集の知見は多く無さそうだったし、今後Prometheusを活用できないのは困るので、練習として。

ただし、EdgeRouter(≒VyOS≒Vyatta) にサービスを追加するのをきちんと取り組もうとする (=vyosのインターフェースで色々と設定できるようにしてあげる) と死ぬほど大変そうなので、一旦はnode_exporterが問題無さそうに動くまで。

自分の記事で扱う範囲は、EdgeRouterにnode_exporterを設置するところまでなので、Prometheusサーバーの構築等は他の記事を参考にしてください。

方針

  1. EdgeRouterをMackerelで監視する方法が世の中に知見として転がっているので、それを真似する。
    • Mackerel-agent も node_exporter も golang で書かれていて、知見の転用がし易いから
  2. EdgeRouter上で追加のサービスをきちんと動かすための知見が少ないのでそこもお手軽にやる。　
  3. メトリクスに関しては後日整備する

やったこと

Prometheusの入門を眺める

knowledge.sakura.ad.jp

node_exporterをコンパイルする。

papix.hatenablog.com

上記を参考にしつつ、以下の様なコンパイル方法に落ち着いた

自分はmacの上でコンパイルして、EdgeRouterに持っていった。

go get github.com/prometheus/node_exporter
cd ${path}/${to}/node_exporter
env GOOS=linux env GOARCH=mipsle go build node_exporter.go

EdgeRouterのCPUは普段使うPCとアーキテクチャが違うけど、こういうときにgolangのクロスコンパイルの便利さが効いてくるなぁと思った。

EdgeRouterにコンパイル後のバイナリを置く

後述するinitスクリプトの兼ね合いで /opt/promehteus/node_exporter にした。

node_exporeter用のinit scriptを設置する

EdgeRouterはinit.d でサービスを取り扱っているので、以下のスクリプトをパクらせてもらって /etc/init.d/node_exporter とした。

Init.d script for prometheus node exporter · GitHub

自分でいじったのは、USERを prometheus から root にしたくらい。

実際の起動

sudo /etc/init.d/node_exporter start

Rebootしても大丈夫にする

EdgeRouterのOSの元になっているDebianとかでは chkconfig はなく、 update-rc.d などを使うことになっているが、 EdgeRouter内には無い雰囲気。

ので、今回はお手軽に /etc/rc.local に /etc/init.d/node_exporter start を追記しておくことにする。

確実にもっといい方法があるのだけど、EdgeRouterのお作法がよくわからなかったので一旦はこれで。

実際の雰囲気

自分のルーターは 172.0.0.1 で動いているので以下のようになった。途切れているのはrebootした所で、監視のダウンタイムは大体3分くらい。

f:id:yaaamaaaguuu:20180128215101p:plain

laptopにnixosをインストールする前後の話

nixos

nixosというlinuxのディストリビューションがある。

大体の話は以下にまとまっている。

github.com

インストール方法も上記のwikiの インストール のページに書いてある。

インストール自体で自分が若干詰まったのは、MBRなのか？GTPなのか？くらいで特に言及することがないのだが、その前後で書き残しておくとnixosに入門したい人の役に立てるのかなぁと思うので、書き残しておく。

インストール前

Installation of NixOS with encrypted root · GitHub

上記を参考にBIOSの画面で、Disable Secure Boot Control と Disable USB legacy boot というのをした。

インストール後

自分が実施したのは以下

  • ネットワークの設定
  • bluetoothの設定
  • フォントの設定
  • non free なソフトウェアを参照するための設定
  • dockerの設定
  • laptopのJISと外付けのHHKBの英字を共存させるための設定

ネットワークの設定

インストールのページで wpa_supplicant 云々と書いてあるが、OSをインストール後, NetworkManagerを入れると良い。

GUI付きのインストーラーだと、ネットワークを設定するウィジェットがあるが、OSインストール後にはないように見える。が、実はNetworkManagerをインストールすることでインストール前見えていたウィジェットが見えるようになる。あとはNetworkManagerが良しなにやってくれる。

nix-env -i NetworkManager

bluetoothの設定

/etc/nixos/configuration.nix に以下を書き込んだ。

  hardware.bluetooth.enable = true;
  hardware.pulseaudio = {
    enable = true;
    package = pkgs.pulseaudioFull;
  };

bluetoothをenableにするだけだと、bluetoothスピーカーとかが良い感じに動かなかった。

フォント

以下のような感じ。

fonts = {
    enableFontDir = true;
    enableGhostscriptFonts = true;
    fonts = with pkgs; [
      ipafont
    ];
  };

non free なソフトウェアを参照するための設定

この設定に気づくのに謎に時間がかかった。

nixpkgs.config.allowUnfree = true;

上記を有効にしておくと、slackとかdropboxとかのクライアントが使えるようになって便利。インストールは上記を有効にしたあとnoxで適当に探すと良い。

nix-env -iA nixos.pkgs.slack
nix-env -iA dropbox

dockerの設定

インストールは nix-env -iA docker

設定は以下

  virtualisation.docker.enable = true;
  virtualisation.docker.enableOnBoot = true;

あとユーザーをdockerグループに属させる

laptopのJISと外付けのHHKBの英字を共存させるための設定

  • 面倒なので割愛
    • 需要があれば書きます。

2017年の振り返りと2018年の抱負

2017年度の振り返り

  • 自分の主戦場がwebからインフラに少しづつシフトしている
  • 出来ること、やってみて理解が出来ることが増えた
    • たぶんネットワークは初学者くらいの力がついたはず
    • フルスクラッチで実装できるものが増えた
    • 馴染みのあるプロトコルならrfcを読んで実装に落とせる様になった
  • 理系卒インフラエンジニアだらけの職場になった
    • 周りの人たちは自分の知らないことを知っていることが自覚できた
    • とくにコンピューターサイエンスの基礎教養的な箇所

「周りの人たちは極々普通のこととして、自分の知らないことを喋る」というのが2017年だったと思う。

  • ネットワークの話し
  • Linuxカーネルの話し
  • FPGAの話し
  • コンピューターの各種インターフェースの話し
  • etc

2018年度の抱負

特に自分はプログラミングやコンピュータとの関わりが短いので、周りの人との知識量の差を埋めていくか？を考えると、2018年は「できないこと、知らないことを減らす」というのが抱負になる。

EdgeRouter X がファクトリーリセットも効かなくなったのを直した話し

EdgeRouter

タイトルどおり。 現状は解決に至っていないので、問題の解決方法を知りたいだけならココを見るのは無駄である。

解決した。

yaaamaaaguuu.hatenablog.com

上記を書いてはや数ヶ月。EdgeRouterは息をしなくなった。当然自宅リージョンは全断の状態で非常に困っている。

いまネットを問題なく使えているのはwifiのアクセスポイントとして使っていたやつを急遽ルーターとして再活躍してもらっているからだ。

死んだルーターは以下のやつ。

Ubiquiti Networks Edgerouter ER-X（日本国内）

Ubiquiti Networks Edgerouter ER-X（日本国内）

先に諸々で現状困っていることを書き残す

  • ルーターがDiskfullで死んでいる
  • コンソール接続ができている
    • 一応ファクトリーリセットが効いている様
      • 既存のユーザーのパスワード等は効かない
    • ただし、リセットの一部の工程は上手くいっていない模様
      • 初期ユーザーのパスワードセットとか user: ubnt, password: ubnt とかが設定されてない
  • シングルモードユーザーでのログインを試みているが上手くいっていない
    • が、EdgeRouterの U-Boot でどうしたらLinuxのbootargsにsingleを渡せるのかが分からない
    • bootargsは一応書き換えられるが、書き換えた状態からU-BootのCLIからbootさせる方法がわかっていない
      • 分かった

作業ログてきなモノ

現状の整理

  • 最近なんか調子が悪かった
    • web UIがすぐ落ちたり
  • EdgeRouterにssh出来ない
    • そもそもpingが到達しない
    • 自宅のルーターだからと言って、気軽になんどかrebootした
  • 筐体のLEDは光っている
  • ファクトリーリセットを何度か実行しても状況が変わらない

思い返す

大丈夫だと思ってさらっと見逃したが、ディスクフルだったのでは?という気がしてきた。

対応策

  1. 2年間の保証があるとのことで対応してもらいたい
    • 代理店？が休業中っぽい 😇
  2. USBでコンソールに繋いでなんとかする
    • 仕方がないので今回はこっち

ER-XにUSBでコンソールにつなぐ

元ネタは以下。

community.ubnt.com

なるほど。USB-TTLで変換するのがあれば、ルーターにはシリアルポートが無いバージョンのやつだけどコンソール接続できそう。

amazonで似たようなやつを調達した。

Rasbee USB-TTLシリアルコンソールのUSB変換COMケーブルモジュールのケーブル Raspberry Pi用 [並行輸入品]

Rasbee USB-TTLシリアルコンソールのUSB変換COMケーブルモジュールのケーブル Raspberry Pi用 [並行輸入品]

現状の作業環境はOSX high sierraなので、ドライバの配布ページ からドライバをダウンロード, インストールして使えるようにして、結線は以下のようにした。

左から、接続なし, 緑, 白, 黒

このMacについて -> システムレポート -> USB でUSB-TTL が接続できているか？が確認でき、

f:id:yaaamaaaguuu:20171218013355p:plain

ターミナル上で、 /dev/tty.usbserial の有無でドライバが正しくインストールできているか？が確認できる。

でもって、minicomというやつを使えば、コンソール接続できるらしいのでおもむろに brew install minocom した。

接続は以下のコマンド

minicom -b 57600 -o -D /dev/tty.usbserial

f:id:yaaamaaaguuu:20171218013706p:plain

色々出ているが、 no space left というワードが決定的

でもって、bootの途中に、boot方法どうする？と聞かれるので 4 を押す。

そのあとに以下を叩いて現状確認

printenv
~~~
bootargs=console=ttyS1,57600n8 ubi.mtd=7 root=ubi0_0 rootfstype=ubifs rootsqimg=squashfs.img rootsqwdir=w rw
~~~

あとはbootargsにsingleを加えてシングルユーザーモードで起動するようにする

setenv bootargs=console=ttyS1,57600n8 ubi.mtd=7 root=ubi0_0 rootfstype=ubifs rootsqimg=squashfs.img rootsqwdir=w rw single
saveenv
boot bfd40000

bootコマンドの引数の理由は、特に何も指定しなかった時のbootのログから Booting image at bfd4000... とあったのでそれに従った。

Please choose the operation:
   1: Load system code to SDRAM via TFTP.
   2: Load system code then write to Flash via TFTP.
   3: Boot system code via Flash (default).
   4: Entr boot command line interface.
   7: Load Boot Loader code then write to Flash via Serial.
   9: Load Boot Loader code then write to Flash via TFTP.
default: 3
 0

3: System Boot system code via Flash.
## Booting image at bfd40000 ...
   Image Name:   Linux Kernel Image
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    1708328 Bytes =  1.6 MB
   Load Address: 80001000
   Entry Point:  803799d0
...........................   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

残作業として、 /root.dev が100%になっていることを確認したらフォーラムに以下の事が記載されていたので、それにしたがって古いファームウェアを消した。

community.ubnt.com

その後rebootしたらいつも通りのEdgeRouterが戻ってきたので、あとは頑張って設定を復旧するのみ 😇