/var/log/study

つまり雑記

systemd環境でDNSの向き先が変わらなかった

2018年の6月9日時点での話です。

Ubuntu18.04でいくら設定を変更しようとしてもDNSの向き先が変わらず若干悩みました。

結論から書くと、/etc/resolve.conf/run/systemd/resolve/resolv.confシンボリックリンクになっていることが期待されているのですが、シンボリックリンクになっていなかっただけです。

以下のリンクの質問と回答がドンピシャでした。

askubuntu.com

ubuntu 18.04 ではnetplanが導入されたので、その設定を変更しても、systemd-networkdの設定をいじっても、頑なに /etc/resolve.conf のnameserver は 127.0.0.53 を向いていたので何事だろうな?と思ったらsystemdのバグとのことでした。

Gitlab Development Kit のテストを回せるようにするための覚書

gitlab.com

↑ に沿えば良いのだけど、多分gitlab development kit (以下gdk) は普段の開発用ラップトップに導入される事をある程度前提としていると思う。

なので、クラウド上に作ったまっさらでしょぼいUbuntuとかにインストールしてもさくっとは動作しないので、セットアップ前後のフォローをこの記事でしたい。

この記事は2018年3月26日に書いている事に注意して頂きたい。

マシンスペック

gitlab自体を動かすrequirementsは以下に書いてある。

docs.gitlab.com

が、あまりにもしょぼいサーバーで bundle exec spec とかやり始めると、色々不都合が多い。

自分が用意した環境は以下

  • マシン
    • VMwareのESXi上に構築
    • ディスクはNFSのHDD
  • OS
  • CPU
    • 4vCPU
    • テストを回している最中のtopやvmstatを見ると、2vCPUでも大丈夫かなぁ?と言う気持ち
  • Memory
    • 16GB
    • swapが出ないように16GBにしたが、もう少しだけ絞っても大丈夫そう
  • Disk
    • 64GB
    • 容量的にギリギリっぽい
    • IOは特に問題にならない模様

set-up-gdk の前にやっておく必要があること

  1. rbenvなどでrubyのランタイムを用意
    • この記事を書いている時点では version 2.3.6
    • rbenv global 2.3.6
    • gem install bundler
  2. nodenvなどでnode.jsのランタイムの用意
    • この記事を書いている時点では version 8.9.4
    • nodenv global 8.9.4
    • npm install -g yarn
  3. chromeのインストール
    • その時の最新で良いと思う
  4. seleniumのchromedriverをインストール
  5. 必要なpostgresqlのバージョンをインストール
    • pg_config コマンドで表示されるバージョンがgitlabの利用するpostgresqlのバージョンとなる
    • pg_configpostgresql-server-dev というパッケージが提供するコマンド
    • postgresqlpostgresql-server-dev でバージョンがずれていないか意識する必要がある

テストを実行するには

  • gitlab-development-kit 配下で
    • gdk run
  • 別端末なりtmuxでの分割なりで
    • seleniumのchromedriverを動かす
      • chromedriver
  • 別端末なりtmuxでの分割なりで
    • gitlab-development-kit/gitlab 配下で
      • selenium周りで問題が無いかチェックする
        • bundle exec rspec spec/features/merge_requests/filters_generic_behavior_spec.rb
      • rspecのテストを回す
        • bundle exec spec

既存のvSphere環境をTerraform import して管理する

yaaamaaaguuu.hatenablog.com

ほぼ1年越しの再入門。既存のvSphere環境を管理するために色々と試してみる

今回は, フォルダとvDS, データストアをインポートして ~planで差分がなくなるところ~ だるかったのでインポートまで。

terraform v0.11.3 で検証

色々試す前の確認事項

ワークフロー

  • 初回のみ
    • terraform init
  • 以降
    1. tf ファイルに既存の構成を書く
    2. terraform import で既存の構成をインポート
    3. terraform plan で確認
  • 変更があれば
    1. tf ファイルを編集
    2. terraform plan で確認
    3. terraform apply で実行

importなりapplyなりをすると、terraform.tfstateが作成される。tfstateに無いものは新規作成としてみなされるっぽい。

でもって、terraform.tfstateをgitで管理する?とかは以下に書いてあるので、適当なタイミングで調査しようと思う。

www.terraform.io

tfファイルの構成

terraformはカレントディレクトリにある tf ファイルを全て読み込んで実行するとの事。

なので一旦はansibleのようにディレクトリ構成は考えずに取り組んでいく

tf内の用語

  • providor
    • 接続情報とか
  • data
    • たぶん参照系
  • resource
    • たぶん自分で作りたいやつ
  • variable
    • 変数

まず接続確認

providor.tf を作り接続確認

variable "vsphere_user" { 
  default = "administrator@vsphere.local" # デフォルトを入れておくと、コマンド実行時に引数を与えなくて済む
}

variable "vsphere_password" { 
  # なにも定義せずに実行すると該当の変数に何を入れるか実行時に聴いてくれる
  # もちろんコマンドラインの引数で与えてもOK
  # ただしterraform import のときはコマンドライン引数に与えてあげる必要がある
}

variable "vsphere_server" { }

provider "vsphere" {
  user           = "${var.vsphere_user}"
  password       = "${var.vsphere_password}"
  vsphere_server = "${var.vsphere_server}"

  # if you have a self-signed cert
  allow_unverified_ssl = true
}

こんな感じのファイルを作った後に、vSphere providoerをインストールするために以下のコマンドを叩く

$ terraform init

Initializing provider plugins...
- Checking for available provider plugins on https://releases.hashicorp.com...
- Downloading plugin for provider "vsphere" (1.3.3)...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.vsphere: version = "~> 1.3"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

するとversionの出力にvsphereのprovidorが追加される

$ terraform --version
Terraform v0.11.3
+ provider.vsphere v1.3.3

そしたら接続確認の為に terraform plan を実行する

$ terraform plan

Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.


------------------------------------------------------------------------

No changes. Infrastructure is up-to-date.

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, no
actions need to be performed.

データセンターを確認する

vsphere_datacenter がデータとリソースで使える

確認するつもりだったが、datacenterはimportに未対応なのでdataで参照系だけ定義しておく

datacenter.tf で。

data "vsphere_datacenter" "my_dc" {
  name = "mycloud"
}
$ tree
.
├── datacenter.tf
├── providor.tf

VMのフォルダ

現状は以下の感じ。

f:id:yaaamaaaguuu:20180311155302p:plain

administration を管理するようにする

インポートする前に既存の定義を書く

administration.tf とする

resource "vsphere_folder" "administration" {
  path          = "administration"
  type          = "vm"
  datacenter_id = "${data.vsphere_datacenter.my_dc.id}"
}
$ tree
.
├── administration.tf
├── datacenter.tf
├── providor.tf

インポートする

https://www.terraform.io/docs/providers/vsphere/r/folder.html#importing

上記を参考に

$ terraform import -var="vsphere_password=####" vsphere_folder.administration /mycloud/vm/administration
vsphere_folder.administration: Importing from ID "/mycloud/vm/administration"...
vsphere_folder.administration: Import complete!
  Imported vsphere_folder (ID: group-v687)
vsphere_folder.administration: Refreshing state... (ID: group-v687)

Import successful!

The resources that were imported are shown above. These resources are now in
your Terraform state and will henceforth be managed by Terraform.

確認する

$ terraform plan

Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

data.vsphere_datacenter.my_dc: Refreshing state...
vsphere_folder.administration: Refreshing state... (ID: group-v687)

------------------------------------------------------------------------

No changes. Infrastructure is up-to-date.

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, no
actions need to be performed.

ネットワーク

既存のネットワークは以下

f:id:yaaamaaaguuu:20180311173226p:plain

myprivate を管理出来るようにする

インポートする前に定義を書く

まずESXiのデータ定義を書く必要があるので、 hosts.tf で以下を書く

variable "esxi_hosts" {
  default = [
    "esxi1.mycloud.local",
    "esxi2.mycloud.local",
    "esxi3.mycloud.local",
  ]
}

variable "network_interfaces" {
  default = [
    "vmnic0",
    "vusb0"
  ]
}

data "vsphere_host" "host" {
  count         = "${length(var.esxi_hosts)}"
  name          = "${var.esxi_hosts[count.index]}"
  datacenter_id = "${data.vsphere_datacenter.my_dc.id}"
}

2こめのnicvusb0 になっているはIntelのNUCにusb nicをくっつけているから。

yaaamaaaguuu.hatenablog.com

$ tree
.
├── administration.tf
├── datacenter.tf
├── hosts.tf
├── providor.tf

次にネットワークのリソースを書く

network.tf

resource "vsphere_distributed_virtual_switch" "myprivate_dvs" {
  name          = "myprivate"
  datacenter_id = "${data.vsphere_datacenter.my_dc.id}"

  uplinks         = ["uplink1"]
  active_uplinks  = ["uplink1"]

  host {
    host_system_id = "${data.vsphere_host.host.0.id}"
    devices        = ["${var.network_interfaces}"]
  }

  host {
    host_system_id = "${data.vsphere_host.host.1.id}"
    devices        = ["${var.network_interfaces}"]
  }

  host {
    host_system_id = "${data.vsphere_host.host.2.id}"
    devices        = ["${var.network_interfaces}"]
  }
}

インポートする

$ terraform import --var="vsphere_password=####" vsphere_distributed_virtual_switch.myprivate_dvs /mycloud/network/myprivate
vsphere_distributed_virtual_switch.myprivate_dvs: Importing from ID "/mycloud/network/myprivate"...
vsphere_distributed_virtual_switch.myprivate_dvs: Import complete!
  Imported vsphere_distributed_virtual_switch (ID: 50 2d 17 35 c3 ea f4 f3-32 64 07 3c 8e 3a d8 8a)
vsphere_distributed_virtual_switch.myprivate_dvs: Refreshing state... (ID: 50 2d 17 35 c3 ea f4 f3-32 64 07 3c 8e 3a d8 8a)

Import successful!

The resources that were imported are shown above. These resources are now in
your Terraform state and will henceforth be managed by Terraform.

plan

terraform plan

すると結構差分が出るので、後はドキュメントを読んで差分を埋める

ストレージ

f:id:yaaamaaaguuu:20180311175223p:plain

現状は上記

import前の定義

storage.tfで以下のように書く

resource "vsphere_nas_datastore" "storage1" {
  name            = "storage1.mycloud.local"
  host_system_ids = ["${data.vsphere_host.host.*.id}"]

  type         = "NFS"
  remote_hosts = ["storage1.mycloud.local"]
  remote_path  = "/data/virtual-machines"
}

import

データストアのインポートにはmoidが必要らしいのでweb clientのurlから適当に拾ってくる

$ terraform import -var="vsphere_password=###" vsphere_nas_datastore.storage1 datastore-11
vsphere_nas_datastore.storage1: Importing from ID "datastore-11"...
vsphere_nas_datastore.storage1: Import complete!
  Imported vsphere_nas_datastore (ID: datastore-11)
vsphere_nas_datastore.storage1: Refreshing state... (ID: datastore-11)

Import successful!

The resources that were imported are shown above. These resources are now in
your Terraform state and will henceforth be managed by Terraform.

plan

terraform plan

ストレージのpalnは特に差分が出ない

一旦まとめ

$ tree
.
├── administration.tf
├── datacenter.tf
├── hosts.tf
├── network.tf
├── providor.tf
├── storage.tf
├── terraform.tfstate
└── terraform.tfstate.backup

こんな感じになった。

Giteaをサクッと動かす

自宅環境の管理にansibleを使いたくなったので、その前にgitのリポジトリを動かすことにした。

gitlabでも良いのだが、最近の動向を見ていると結構色々なものがついてきて重厚な印象があったので、今回はGiteaにした。

github.com

検証は以下のバージョンで実施した。

https://github.com/go-gitea/gitea/commit/b333e7129d26abb64cdd34e67e39cfe34fdf5bb1

動かしたか

自宅に閉じた環境なのでhttpオンリー。ホスト側の適当なポートとコンテナ内の22をつなぐとsshでも利用できると思われる。

データディレクトリをマウントしているのは、その配下に色々とデータが書かれるため。

docker run -d -v ${PWD}/data:/data/ -p 3000:3000 gitea/gitea:latest

リポジトリの見た目

f:id:yaaamaaaguuu:20180311022841p:plain

気づいたこと

  • 特に期待していなかったが、日本語対応がシッカリしている。
  • リポジトリの機能
    • 普通のリポジトリ
      • コミットごとの差分の普通に見れる
    • MR
    • issue
    • wiki
    • リリース
    • アクティビティログ
  • オーガニゼーションが作れる

今後運用してみて知見が溜まったらまたブログにまとめる

RubyのProcess.detachを学ぶ

タイトルの通り。

マルチプロセスなEchoサーバーをRubyで書く際に、なるべくRubyの便利機能を排除して書きたかった。

Echoサーバー程度だとそもそも規模が小さいのでほぼ問題なく書けるのだが、子プロセスの扱いだけを悩んでしまった。

特に子プロセスの終了を親側で待つ必要が無いが、子プロセスの状態を回収しないとゾンビプロセスが発生してしまう。

ゾンビプロセスが湧くのはプロセスを見たときにイマイチなので回避したい。 そんなときにRubyの便利機能 Process.detach を見つけた。

どんな方法で実現されているのか?を知りたいのでコードを見ることにする。

github.com

サーッと、 Rubyprocess.c というファイルを眺めていると、proc_detachProcess.detach の実装に相当していそう。

色々とコメントが付いている。

https://github.com/ruby/ruby/blob/trunk/process.c#L1132-L1175

雑に要約すると以下。

  • マルチプロセスなプログラムで親プロセスが、子プロセスのステータスを回収しないと、子プロセスがゾンビになるよ
  • それを防ぐために、 detach ではメインのスレッドと、子プロセスを待つスレッドを分けるよ
  • 子プロセスを明示的に待つ必要がない時に利用してね

コメントにユースケースとかデザインとかがしっかり書き込まれているのは便利。

ESXi6.5にUSB 3.0のLAN Adaptorでnicを増やす

タイトルの通り。

ESXi6.5にUSB 3.0のLAN Adaptorでnicを増やしたかった。

手順は以下の通り。

https://norikichi.net/?p=1522

このブログで伝えたいことは、上記の手順が、以下の商品でも問題なく動作したよ!って事。

あと、ESXiは一度Rebootしないとnicが認識されなかった。 もしかしたらネットワークのリスタートでも良いのかもしれない。

iron functions の web uiを試す

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