Tag: ansible
A deep dive into my Forgejo setup
I've finally found the will to setup my own personal Git forge. In this article I'm going to present in details my set up and discuss pros and cons that come with it
Setting Up a Git Server on K3S with Gitea
Running a local git server and deployment pipeline using Gitea
2025年にもなって VPS を再び借りましたのメモ
なぜ再び借りようと思ったのかは絶対に忘れてしまうのでお気持ち残しておこう
Centralise GNU/Linux email delivery like it's 2020
The technological side of Email has always occupied a bittersweet corner in my nerdy heart. In this article I dive a bit in the history of SMTP and share a simple but effective solution that I currently use to rationalise system and users' email delivery for a few of the Linux systems I manage.
Automate router WiFi bridge setup with Raspberry Pi, Node.js, Puppeteer and Ansible
Automate router WiFi bridge setup with Raspberry Pi, Node.js, Puppeteer and Ansible
nginx-proxy を使った Docker ベースの検証をしてたらリバースプロキシが急に表示できなくなった
メモとして残しておきます。 ansible-playbook で急に表示できなくなった 本番環境の CentOS7 と、その検証環境（Vagrant on Mac）で Ansible 経由で Docker をインストールして使っていたのですが、 ある日 ansible-playbook を実行すると急に表示できなくなりました。 （Chef を使ってたころはこういうの頻発してたなあ・・・） その間は Vagrant のアップデートくらいしかしてなかったので、 順に確認していくことに。 各種ログ nginx-proxy のログは lrwxrwxrwx 1 root root 11 Aug 24 03:51 access.log -> /dev/stdout lrwxrwxrwx 1 root root 11 Aug 24 03:51 error.log -> /dev/stderr のような感じで、特に何も指定してなければ外にログとして出るようになってます。 docker logs -f nginx-proxy などとしてログを表示させたりしても特に問題は見受けられず。 また、 /etc/nginx/conf.d/default.conf のファイルも特に問題なく、 コンテナが作られると適切に設定が書き換わっているようでした。 自動と手動 次に ansible のレイヤーで問題が起きている可能性を考えて、 自動で作った Docker コンテナをそのまま手動で作ってみました。 するとコンソールに見慣れないメッセージが。 WARNING: IPv4 forwarding is disabled. Networking will not work. なんだこれ。
Ansible の playbook 内で条件分岐を行う方法
これも公式に詳しく書いてなくて出来るのを分かってなかったので 僕と同じようなところで困っている人のためにメモっておきます。 jinja2 Ansible では jinja2 というテンプレートエンジンが利用されています。 playbook 内で {{ ssh_port }} などの記述を埋め込むことで 外部の設定ファイルから ssh_port の値を環境に応じて出し分けることが可能です。 僕の場合は、ローカル（VirtualBox + Vagrant）環境と本番環境とで 設定値が異なるところを括り出して、Ansible の group_vars ディレクトリ以下に 環境ごとのファイル名をつけて保存しています。 Ansible 関係なく、jinja2 のテンプレートエンジンの解説ページが 以下にあります。 Template Designer Documentation — Jinja Documentation (3.2.x) jinja.pocoo.org こちらを見ると分かるように、Ansible の playbook 以外にも HTML や XML などにも幅広く利用されているようです。 デリミタ（delimiter、区切り文字のこと）の種類として、以下の4つが使えるものとして挙げられています。 {% … %} for Statements {{ … }} for Expressions to print to the template output {# … #} for Comments not included in the template output … ## for Line Statements このうち、Ansible の playbook でよく使われるのが {{ ... }} の式の実行結果が出力できるやつで、 それ以外のものは公式のドキュメントにはほぼ見かけません。
Ansible で Docker のインストール
Ansible で再起動後にも playbook を継続する方法 で 再ログインに関しても一緒にまとめておこうと思ったのですが、 Docker の方が話の割合として多くなりそうだったので別記事でまとめておきます。 特に Ansible で Docker をインストールするときはこれに該当するんじゃないかと思います。 Ansible で Docker まず話がややこしくならないように事前に触れておきますが、 Ansible & Docker の話は複数あって、 Ansible の playbook の実行（の検証？）に Docker コンテナを用いる話 Ansible の playbook で Docker をインストールする話 が挙げられますが、今回は 1 ではなく 2 の話です。 ちなみに 1 についてですが、 例えばローカルに用意した VirtualBox や外部に借りている VPS の環境だったり、 SSH がつながる環境であれば Ansible の実行は可能ですが、 それが Docker コンテナまで利用できるように広がってきたよという話です。 （僕も詳しくないのでここまでしか把握してません。） 詳しくは “ansible docker connection plugin” でおググりください。 Docker インストール時のグループ追加について 手動でやっててけっこうはまった箇所なのですが、 各種 docker コマンドを実行する際は、sudo をつけて実行するか、 docker グループにユーザーを追加してから docker コマンドを実行する必要があります。
Ansible で再起動後にも playbook を継続する方法
タイトルの通りですが、正直これ出来ないと思っていたので、出来てすごく嬉しいです。 Chef では少なくともそういった機能は無かったように思えますが（僕が知らないだけかもしれない）、 Ansible はプッシュベース だからでしょうか。 実行する主体がいつもローカル側にあるからこそ、 一旦接続を切ってまた繋げるといったことがやりやすいのかもしれません。 そもそもなぜ再接続したいのか？ ほとんどの playbook では問題ないのですが、 SELinux の設定の反映（一時的な設定だけなら問題なし）などの一部のセットアップにて、 再起動が必要になるものが存在しています。 他にもあるかもしれませんが、 例えば SELinux の設定をいじる場合は以下のような手順を踏みます。 $ getenforce #=> 今の設定確認 Enforcing $ sudo vi /etc/sysconfig/selinux #=> SELINUX=disabled を設定 $ sudo reboot #=> 再起動 Ansible では playbook 上で reboot すると、 playbook のステータスが unreachable になってそのまま終了 してしまいます。 fatal: [machine_name]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh.", "unreachable": true} 繋がらなくなるのでまあ当然ですよね。 これを一連の playbook で再起動をはさんで実行できると、 playbook を書くときにトリッキーなことをせずに済むこともあるかもしれません。 （SELinux だけみると、最後にまとめて再起動すれば事足りるっちゃあそうですが・・・。）
Chef を捨てて Ansible に移行した
前の記事の WordPress を捨てて Hugo に移行した よりも前に、 ずいぶん前に “Chef を捨てて Ansible に移行” していたのですが、 書いておかないと忘れるので自分用にメモしておきます。 プロビジョニングツールを使い始める前の自分 Chef を利用する前は、 いわゆる プロビジョニングツール というのものを一切使っておらず、 サーバの構築はそのマシンでうまく行くまで何度も行う、 トライアンドエラーのようなサーバ構築を行っておりました。 こういうのって、ちゃんとコマンドラインで入力した内容をメモるなりして きちんと手順化していかないと、 すぐに忘れたりして環境の再現ができなかったりするんですよね。 最初は実機に対して直接作業を行うことが多かったので、 普段慣れない端末への入力だったり、異なる OS でのオペレーションなども相まって 上手くインストールできないと結構なストレスを感じることも多くありました。 そのうち、実機にそのまま試すのではなく、サンドボックスのような自由に試せる環境を 予め用意し、まずはそっちで試してみようと思い、 VirtualBox + Vagrant を導入して 自分のマシン上に対象となる Linux マシンと同一の環境を作り、 先にそちらで試すようになりました。 それと同時に、非常に簡易的ではありますが、 シェルスクリプトベース の手順書のようなものを自分で用意するようになり、 よくある一般的なサーバのセットアップ作業程度であれば 素早く再現できるようになりました。 ここまで来てようやく サーバのセットアップ手順をまとめることへの重要性 に 段々と気づくようになってきます。 Chef を導入し使い始めたころの自分 手元の環境をローカル、セットアップ対象をリモートとすると、 Chef 自体をリモートの方にインストールする必要 があったのですが、 Vagrant のプラグインである vagrant-omnibus を利用して 初回起動時に自動的に Chef をインストールできたことでだいぶ楽できました。 Chef の Cookbook と呼ばれる手順書のファイル群を自分で書くか、 あるいは Welcome - The resource for Chef cookbooks - Chef Supermarket Supermarket is Chef's open-source community platform. Find, explore and view Chef cookbooks for all … supermarket.chef.io などで公開されている サードパーティ製の Cookbook を利用するなどして、 シェルスクリプトベースで書かれていた秘伝のタレになりつつあった手順書を なんとか汎用化していこうと思い、少しずつ置き換えを進めていきました。