systemd環境でDNSの向き先が変わらなかった
2018年の6月9日時点での話です。
Ubuntu18.04でいくら設定を変更しようとしてもDNSの向き先が変わらず若干悩みました。
結論から書くと、/etc/resolve.conf
は /run/systemd/resolve/resolv.conf
のシンボリックリンクになっていることが期待されているのですが、シンボリックリンクになっていなかっただけです。
以下のリンクの質問と回答がドンピシャでした。
ubuntu 18.04 ではnetplanが導入されたので、その設定を変更しても、systemd-networkdの設定をいじっても、頑なに /etc/resolve.conf
のnameserver は 127.0.0.53
を向いていたので何事だろうな?と思ったらsystemdのバグとのことでした。
Gitlab Development Kit のテストを回せるようにするための覚書
↑ に沿えば良いのだけど、多分gitlab development kit (以下gdk) は普段の開発用ラップトップに導入される事をある程度前提としていると思う。
なので、クラウド上に作ったまっさらでしょぼいUbuntuとかにインストールしてもさくっとは動作しないので、セットアップ前後のフォローをこの記事でしたい。
この記事は2018年3月26日に書いている事に注意して頂きたい。
マシンスペック
gitlab自体を動かすrequirementsは以下に書いてある。
が、あまりにもしょぼいサーバーで bundle exec spec
とかやり始めると、色々不都合が多い。
自分が用意した環境は以下
- マシン
- OS
- CPU
- 4vCPU
- テストを回している最中のtopやvmstatを見ると、2vCPUでも大丈夫かなぁ?と言う気持ち
- Memory
- 16GB
- swapが出ないように16GBにしたが、もう少しだけ絞っても大丈夫そう
- Disk
- 64GB
- 容量的にギリギリっぽい
- IOは特に問題にならない模様
set-up-gdk の前にやっておく必要があること
- rbenvなどでrubyのランタイムを用意
- この記事を書いている時点では version
2.3.6
rbenv global 2.3.6
gem install bundler
- この記事を書いている時点では version
- nodenvなどでnode.jsのランタイムの用意
- この記事を書いている時点では version
8.9.4
nodenv global 8.9.4
npm install -g yarn
- この記事を書いている時点では version
- chromeのインストール
- その時の最新で良いと思う
- seleniumのchromedriverをインストール
- その時の最新で良いと思う
- https://chromedriver.storage.googleapis.com/index.html で確認できる
- 一番下にあるのは最新ではなく、数字が大きいやつが最新
- 必要なpostgresqlのバージョンをインストール
pg_config
コマンドで表示されるバージョンがgitlabの利用するpostgresqlのバージョンとなるpg_config
はpostgresql-server-dev
というパッケージが提供するコマンドpostgresql
とpostgresql-server-dev
でバージョンがずれていないか意識する必要がある
テストを実行するには
既存のvSphere環境をTerraform import して管理する
ほぼ1年越しの再入門。既存のvSphere環境を管理するために色々と試してみる
今回は, フォルダとvDS, データストアをインポートして ~planで差分がなくなるところ~ だるかったのでインポートまで。
terraform v0.11.3 で検証
色々試す前の確認事項
ワークフロー
- 初回のみ
terraform init
- 以降
-
tf
ファイルに既存の構成を書く -
terraform import
で既存の構成をインポート -
terraform plan
で確認
-
- 変更があれば
-
tf
ファイルを編集 -
terraform plan
で確認 -
terraform apply
で実行
-
importなりapplyなりをすると、terraform.tfstateが作成される。tfstateに無いものは新規作成としてみなされるっぽい。
でもって、terraform.tfstateをgitで管理する?とかは以下に書いてあるので、適当なタイミングで調査しようと思う。
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のフォルダ
現状は以下の感じ。
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.
ネットワーク
既存のネットワークは以下
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こめのnicが vusb0
になっているはIntelのNUCにusb nicをくっつけているから。
$ 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
すると結構差分が出るので、後はドキュメントを読んで差分を埋める
ストレージ
現状は上記
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にした。
検証は以下のバージョンで実施した。
https://github.com/go-gitea/gitea/commit/b333e7129d26abb64cdd34e67e39cfe34fdf5bb1
動かしたか
自宅に閉じた環境なのでhttpオンリー。ホスト側の適当なポートとコンテナ内の22をつなぐとsshでも利用できると思われる。
データディレクトリをマウントしているのは、その配下に色々とデータが書かれるため。
docker run -d -v ${PWD}/data:/data/ -p 3000:3000 gitea/gitea:latest
リポジトリの見た目
気づいたこと
- 特に期待していなかったが、日本語対応がシッカリしている。
- リポジトリの機能
- オーガニゼーションが作れる
今後運用してみて知見が溜まったらまたブログにまとめる
RubyのProcess.detachを学ぶ
タイトルの通り。
マルチプロセスなEchoサーバーをRubyで書く際に、なるべくRubyの便利機能を排除して書きたかった。
Echoサーバー程度だとそもそも規模が小さいのでほぼ問題なく書けるのだが、子プロセスの扱いだけを悩んでしまった。
特に子プロセスの終了を親側で待つ必要が無いが、子プロセスの状態を回収しないとゾンビプロセスが発生してしまう。
ゾンビプロセスが湧くのはプロセスを見たときにイマイチなので回避したい。 そんなときにRubyの便利機能 Process.detach
を見つけた。
どんな方法で実現されているのか?を知りたいのでコードを見ることにする。
サーッと、 Rubyの process.c
というファイルを眺めていると、proc_detach
が Process.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を増やしたかった。
手順は以下の通り。
このブログで伝えたいことは、上記の手順が、以下の商品でも問題なく動作したよ!って事。
あと、ESXiは一度Rebootしないとnicが認識されなかった。 もしかしたらネットワークのリスタートでも良いのかもしれない。
UGREEN LANアダプタ USB3.0 RJ45 ギガビットイーサネット 有線LAN 1000Mbps高速転送 Windows/Mac OS対応
- 出版社/メーカー: UGREEN GROUP LIMITED
- メディア: Personal Computers
- この商品を含むブログを見る
iron functions の web uiを試す
上記の続き
iron functions の web ui はきちんと開発されているよう
動かしてみる
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などにまとめたほうが良いのかもしれないが。
UIから出来ることは以下。
- プロジェクトを作る
- プロジェクト配下のルーティングとキックするコンテナを指定する
- 当然ルーティングの編集、削除も出来る
- 指定したルーティングのキックをする
- IronFunctionsのSwaggerに飛べる
UIを眺めていて、特にルーティングとキックするイメージの指定の際は、結構細かいことを指定可能な事が認識できた。 タイムアウトとか並列度とかは後日試そうと思う。
プロジェクト内のスクショ
新しいルーティングのスクショ
ルーティングを走らせるUIのスクショ