Ansible Tower 3.8をインストールする

Ansibleもくもく会で「Ansible Tower便利だなー」となったのでRed Hat Developer Programを活用してインストールし、遊んでみます。

商用利用や商用検証などには制約があるので、その場合はライセンスを買うかAWXコミュニティに参加してください。

また、本内容は下記ブログを参考にしています。 zaki-hmkc.hatenablog.com

導入前準備

RHELサーバを構築します。 システム要件は下記を参考にしてください。

docs.ansible.com

内容を見ると2Core CPU / 4GB RAM / 20GB DiskSpaceを持つRHELまたはCentOSサーバがあると良いようです。 ただし、AutomationHubのRAM要求が4GBでは足りないようで、インストールで怒られるようです。 (Automation HubのRequireってどこに書いてあるんでしょう?)

適当に4Core / 8GB / 100GBのVMにRHEL8.3をインストールしましたが、ご家庭で触る限りには快適に使えています。

インストーラの入手

Developer Programに参加後、下記URLからインストーラをダウンロードします。 今回はPlatform 1.2を使いました。

Red HatCDNからダウンロードしてくるようですが、1回数kb/sしか落ちない悲しい時がありました。そんな時はキャンセルして再ダウンロードをするとすぐ落ちてきたのでご参考まで。

developers.redhat.com

インストール設定

ファイルを展開し、Inventoryファイルに設定を投入します。 tar.gzだけど無圧縮トラップ…は回避して

$ file ansible-automation-platform-setup-bundle-1.2.0-1.tar.gz
ansible-automation-platform-setup-bundle-1.2.0-1.tar.gz: POSIX tar archive (GNU)
$ tar xf ansible-automation-platform-setup-bundle-1.2.0-1.tar.gz
-bash: tar: コマンドが見つかりません

…最小インストールしてたのでtarがなかったようです。

# dnf install tar

気を取り直して展開し、フォルダの中にあるinventoryファイルを編集します。

$ tar xf ansible-automation-platform-setup-bundle-1.2.0-1.tar.gz
$ cd ansible-automation-platform-setup-bundle-1.2.0-1
$ ls
README.md  backup.yml  bundle  collections  group_vars  install.yml  inventory  licenses  rekey.yml  restore.yml  roles  setup.sh

シングルホストであれば設定すべき箇所は、下記4か所「ここ」のパスワード設定です。

[all:vars]
admin_password='ここ'

pg_host=''
pg_port=''

pg_database='awx'
pg_username='awx'
pg_password='ここ'
pg_sslmode='prefer'  # set to 'verify-full' for client-side enforced SSL

# Automation Hub Configuration
#

automationhub_admin_password='ここ'

automationhub_pg_host=''
automationhub_pg_port=''

automationhub_pg_database='automationhub'
automationhub_pg_username='automationhub'
automationhub_pg_password='ここ'
automationhub_pg_sslmode='prefer'

アプリケーション(Tower/AutomationHub)のadminパスワードと、それぞれのDBのパスワードです。

インストール

setupを実行するとインストールが始まります。最初にAnsibleをインストールし、その後Playbookによって導入するようです。 failed=0で成功と表示されたらインストール完了です。

# ./setup.sh
[warn] Will install bundled Ansible
Updating Subscription Management repositories.
(略)
PLAY RECAP *******
localhost                  : ok=191  changed=79   unreachable=0    failed=0    skipped=86   rescued=0    ignored=2

The setup process completed successfully.
Setup log saved to /var/log/tower/setup-2021-04-18-14:43:11.log.

PostgreSQLの起動に失敗する

Playbookの実行が下記箇所でエラーになり止まることがあります。

TASK [restart postgresql when authentication settings changed] **************
fatal: [localhost]: FAILED! => {"changed": false, "msg": "Unable to restart service postgresql: Job for postgresql.service failed because the control process exited with error code.\nSee \"systemctl status postgresql.service\" and \"journalctl -xe\" for details.\n"}

ログを見ると、postgresql.confに記述されたen_US.UTF-8に不備があるらしく、どうやら日本語でインストールされたRHELには該当のlocaleが含まれていないため起動できないようです。

-- Unit postgresql.service has begun starting up.
 4月 18 14:38:32 rhel8-test postmaster[10159]: < 2021-04-18 05:38:32.769 UTC  >LOG:  パラメータ"lc_messages"の値が不正です: "en_US.UTF-8"
 4月 18 14:38:32 rhel8-test postmaster[10159]: < 2021-04-18 05:38:32.769 UTC  >LOG:  パラメータ"lc_monetary"の値が不正です: "en_US.UTF-8"
 4月 18 14:38:32 rhel8-test postmaster[10159]: < 2021-04-18 05:38:32.769 UTC  >LOG:  パラメータ"lc_numeric"の値が不正です: "en_US.UTF-8"
 4月 18 14:38:32 rhel8-test postmaster[10159]: < 2021-04-18 05:38:32.769 UTC  >LOG:  パラメータ"lc_time"の値が不正です: "en_US.UTF-8"
 4月 18 14:38:32 rhel8-test postmaster[10159]: < 2021-04-18 05:38:32.769 UTC  >FATAL:  設定ファイル"/var/lib/pgsql/data/postgresql.conf"にはエラーがあります
 4月 18 14:38:32 rhel8-test systemd[1]: postgresql.service: Main process exited, code=exited, status=1/FAILURE
 4月 18 14:38:32 rhel8-test systemd[1]: postgresql.service: Failed with result 'exit-code'.
-- Subject: Unit failed
# locale -a
C
C.utf8
POSIX
ja_JP.eucjp
ja_JP.utf8

該当のconfはroles/postgres/templates/postgresql.conf.j2にありますので、該当箇所を導入されている日本語を使うように書き換えてもよいのですが、個人的にはログは英語で出てきてほしいので、下記の通り言語パックを導入します。

# dnf install glibc-langpack-en
# locale -a
(略)
en_US
en_US.iso885915
en_US.utf8
(略)
ja_JP.eucjp
ja_JP.utf8

導入後は再度セットアップを実行すれば大丈夫です。

ログイン & ライセンス認証

ブラウザでHTTPSアクセスし、inventoryに設定したパスワードでadminユーザにログイン、その後DeveloperProgramのアカウントでライセンス認証をしたらセットアップ完了です。

お疲れさまでした!

Zabbix 5.x(latest)をDocker Composeで動かす

ふと年始に自宅Zabbixをコンテナに移行したくなったので、Docker Composeで動かすためにやったことをメモに残す。

想定読者

  • Zabbixの構築・運用経験がある人
    • Zabbix起動後の初期セットアップ方法などは割愛
  • DockerやDocker Composeしたことがある人
    • Docker等のインストール方法は割愛

環境

  • OS : Ubuntu Server 20.04.1 LTS
  • Docker : 20.10.1
  • Docker-compose : 1.25.0

インストール

0. 想定環境

Zabbix Server

  • コンテナで実行する

Zabbix Agent2

  • コンテナではなく、ホストOSにインストールする
    • 今後ホスト上で監視項目を追加していきたいと思ったときに、監視対象へのアクセス権などの制御や運用がコンテナだと面倒そうだなと思ったので
    • Zabbix Agent自身と他のアプリケーションの干渉があまり想定できなかったため

0. インストールドキュメント

5 INSTALLATION FROM CONTAINERS

基本的に上記オフィシャルドキュメントに記載されている内容をベースに進めていく。

1. 構成ファイルの取得

zabbix / zabbix-docker をクローンする。

$ git clone https://github.com/zabbix/zabbix-docker.git

2. Server構成の選択

README.mdのUsageやインストールドキュメントに記載があるように、複数のcomposeファイルが含まれている。 選択肢として下記の選択が与えられており、好きなものを選べばよい。 - ベースイメージ : alpine or Centos or Ubuntu - データベース : MySQL or PostgreSQL - コンテナイメージのビルド : 最新のビルド済みイメージを使用する or ローカルでビルドする

今回は下記理由によりalpine & MySQL & latestを選択し、docker-compose_v3_alpine_mysql_latest.yamlを選定することとした。 - コンテナ内を弄るつもりがないので運用上UbuntuCentOSが使いやすいとかもなく、alpineが一番スリムであったため - Zabbix + MySQLで過去に運用しており、特にPostgreSQLを使わなければならないようなライセンス上の都合もなかったため - ローカルでビルドする必要性がなく、既にベンダー側でテスト済みのイメージを利用したほうが変にはまる要素がないと思ったため

選定したyamlファイルをdocker-composeファイルとしてコピーする。

$ cd zabbix-docker
$ cp docker-compose_v3_alpine_mysql_latest.yaml docker-compose.yaml

(参考)ファイル構成

クローンしたリポジトリは、下記のようなファイル・ディレクトリが含まれている。

ほぼすべてのディレクト

  • 中にalpine,centos,ubuntuディレクトリが含まれており、各ベースイメージからコンテナイメージをビルドするためのDockerfileが含まれている
  • latestを選択すると使うことはないはず

.env_から始まるファイル

  • Zabbixサーバを構築する際に与える必要のある変数が含まれるファイル
    • zabbix_server.confなどに与える値も含む
  • デフォルトのままでも起動可能
  • 必要に応じて編集する

.MYSQL_ or .POSTGRES_から始まるファイル

  • DBのシークレット情報を持つファイル
  • デフォルトのままでも起動可能、必要に応じて編集する。
  • User名やパスワードは変更するべき?
    • DBはホストOSから外へはポートを公開していない
    • ホストOSからは接続可能なため、万が一ホストがやられた際のデータ保護のためには必要…でもホストがやられているときは手遅れでは

docker-compose_v3_から始まるファイル

  • docker-composeファイル
  • 前述の通り選択してcpして利用する。

なお、docker-compose up後からzbx_envディレクトリが生成され、コンテナが使用するデータが保存されていく。別の場所が良いのであれば頑張ってyamlの記述を置換する。

3. docker-compose.yamlの編集

必要なコンポーネントの選択

本ファイル内には下記コンポーネントが含まれており、services内で不要なものがあればコメントアウトもしくは該当箇所を削除する

  • Zabbix Server(必須)
    • zabbix-server
  • Zabbix Proxy(不要または選択)
    • zabbix-proxy-sqlite3
    • zabbix-proxy-mysql
  • Web(選択)
  • Zabbix Agent(不要または選択)
    • zabbix-agent
  • その他(不要または選択)
  • DB(必須)

今回は下記services以外はすべて削除した

- zabbix-server
- zabbix-web-apache-mysql
- zabbix-snmptraps (SNMPトラップ監視のため)
- mysql-server
- db_data_mysql

Zabbix-ServerのIP固定

ホストOS上でインストールしたZabbix Agentと通信する際は、DockerのNetworkで通信を行う。zabbix_agent2.confにZabbix ServerのIPを記載する必要があるが現在の状態では与えられた下記ネットワークIPプールから順次IPが割り当てられるため、起動毎にIPが変化する。

networks:
  zbx_net_frontend:
    driver: bridge
    driver_opts:
      com.docker.network.enable_ipv6: "false"
    ipam:
      driver: default
      config:
      - subnet: 172.16.238.0/24

そのため、Zabbix ServerのIPを固定化する。今回はデフォルトで記載されている172.16.238.0/24から172.16.238.100を使用する。

下記のようにipv4_address: 172.16.238.100を追記する。

services:
 zabbix-server:
  image: zabbix/zabbix-server-mysql:alpine-5.2-latest

(中略)

  networks:
   zbx_net_backend:
     aliases:
      - zabbix-server
      - zabbix-server-mysql
      - zabbix-server-alpine-mysql
      - zabbix-server-mysql-alpine
   zbx_net_frontend:
     ipv4_address: 172.16.238.100

4. env_の編集

.env_web

PHPのTimeZone設定をJSTにする。下記内容を記述。

PHP_TZ=Asia/Tokyo

.env_srv

zabbix_server.confで設定しなければならない内容を記述する。 今回はESXiを監視するために下記内容を追記し有効化及び監視間隔の調整を実施。

ZBX_STARTVMWARECOLLECTORS=4
ZBX_VMWAREFREQUENCY=300
ZBX_VMWAREPERFFREQUENCY=300

5. 起動

$ sudo docker-compose up -d

6. ブラウザでアクセス

http://<HostIP>/にアクセスし、初期アカウントでログインできることを確認。

7. Zabbix Agent2のインストール

Download and install ZabbixからAgentに必要な箇所を抜粋

$ wget https://repo.zabbix.com/zabbix/5.2/ubuntu/pool/main/z/zabbix-release/zabbix-release_5.2-1+ubuntu20.04_all.deb
$ sudo dpkg -i zabbix-release_5.2-1+ubuntu20.04_all.deb
$ sudo apt update
$ sudo apt install zabbix-agent2

その後、/etc/zabbix/zabbix_agent2.confで固定化したサーバのIPを指定してサービスを再起動、ZabbixServer側からもZabbixAgentのIPをホストの127.0.0.1からホストのIPに変更して保存すればホストOSの監視が開始される。

また、zabbixユーザを下記コマンドでdockerグループに参加させ、dockerテンプレートと結びつけると、コンテナの監視が追加される。

$ sudo gpasswd -a zabbix docker

FIFAをPS4からPCに移籍して1年がたったのでいろいろまとめる

約1年前、PS4からPCにサッカーゲームFIFAのプレイ環境を移行しました。

1年プレイしてメリデメや感じたことをまとめます。

きっかけ

技術検証用にノートPC鯖を使っていたのですが、CPU能力がそこそこ高くメモリを多く詰めるマシンが欲しくなりました。 そこで思い切ってデスクトップPCを自作することにし、ついでだからとGPUを1枚購入し当時唯一持っていた据置型ゲーム機PS4と統合を計りました。

PS4で発売される好みのゲームのほとんどがPCで展開されており、PS4の置き場所が無駄に感じたからです。最終的には手放すのが面倒でつい先日まで1年間放置されていましたが、結果としてPCに移行は完了しています。

PC版のデメリット

Ultimate Teamには厳しい

選手市場が厳しい

プレイ人口がPS4XBOXと比べると圧倒的に少ないのか、出品数が少ない選手が多々います。 結果として使いたい選手を高値で買う必要や、SBC用の希少な選手を手に入れることができないことがあります。

レートのボーダーが厳しい

Squad Battlesのレートボーダーが高いです。特にエリート帯より上は。1試合あたりに貰えるポイントも変わらないのに、これだけ格差が出てくるとちょっとやる気がなくなります。 詳細はfutbinというコミュニティサイトのランキングを直接見てご確認ください。

情報が少ない

各選手の能力値やアップデート内容については、PS4XBOXと共通です。 しかし、前述の通り選手市場が大きく異なり相場が一致していません。

選手相場を収集して提供してくれる各コミュニティサイトはPS4XBOXについては双方収集してくれているのですが、PCになるとFutbinぐらいしか集めていないのではないかと思います。(要調査)

公式esports大会からは除外されている

公式esports大会のレギュレーションとして、PS4またはXBOXと明記されています。 まぁesportsやってる人はわざわざPCに乗り換えて据置型を手放す人はいないと思いますが…

PC版のメリット

ゲーム(サブスクリプション)の価格が安い

PCでプレイする場合は、OriginまたはSteamで購入する形になると思います。名前だけで見ると一般的に普及しているSteamで購入したくなりますが、Originにはサブスクリプションサービス「Origin Access Premier」があるのが特徴です。

Origin Access Premiereは年額10,644円でEAのタイトルが発売日からプレイ可能なサブスクリプションです。また多くのタイトルにおいて最上位エディション相当の特典が付属します。

つまり、FIFAに関してはULTIMATE EDITIONがサブスクリプションに含まれるため、この時点で通常価格12,700円(FIFA20)より安くお得になります。

また興味があるようであれば、「Sims 4」や「STAR WARS JEDI FALEN ORDER」などもついてくるので、年に2タイトル以上EAの新作タイトルをプレイするのであれば、非常にお得感が出ると思います。

ゲーム専用機を持つ必要がない

最近はデスクトップPCを持つ家庭も多くなってきたかと思いますが、その場合それなりのGPUがあればわざわざゲーム専用機のために置き場を用意する必要がなくなります。 GPUFIFAの場合、”現時点では”そこまでハイスペックなグラボを求められないのがうれしいところです。

ただし、FIFA22あたりからは据置型次世代機の影響を受けて推奨環境が上がると思われるので、どうなるかなと気になるところです。 私が今使っているGPUはGTX1660なので、買い替えは必要なのかなー。

オフライン関しては(恐らく)一緒なので、オフ専ならデメリットなし

キャリアモードについては、特に上記のようなデメリットは発生していないかと思います。

おわりに

簡単に1年間で感じたことを書き起こしてみました。 FIFA21もあと2か月ぐらいで発売されるかと思います。 この記事が、新バージョンをきっかけに乗り換えを検討している方への参考になればと思います。

httpd 2.2.x や bind 9.8.x がEoLで危険だから使ってはいけない…とは必ずしも言えない話

はじめに

最近よく、OSS脆弱性修正がリリース…なんてニュース多く見ますよね。 対応しなきゃってrpm -qaとかしたところ、あれ…私のバージョン低すぎ…!なんて思うこともあると思います。

調べてみたら、公式ページにApache httpd 2.2 End-of-Life 2018-01-01とか書いてあるし、 でもyum searchで探しても2.4.xは出てこないし…自分でmakeするしかない!?と思ったあなた、実はそのhttpd 2.2はサポート終了していないかもしれません。

バックポート

Backporting Security Fixes : https://access.redhat.com/security/updates/backporting/

多くの商用ディストリビューションでは、バックポートという仕組みが存在します。 要約すると、OSリリースタイミングにおいてサポートされていたパッケージバージョンを、OSSサポート終了後も独自に脆弱性修正を続けていく仕組みです。 詳しくは上のRed Hatのリンクを読んでください。

パッケージバージョンがメジャーバージョンアップされてしまうと、機能互換の問題が発生してしまうことがあるため、運用エンジニアとしては不必要なメジャーバージョンアップは望んでいません。 そういうエンジニア向けに脆弱性修正への対応作業が軽減されるように、影響が最小限になるよう元のパッケージに問題の修正を適用する形でマイナーバージョンアップを提供しています。

そのため本記事のタイトルにあるhttpd 2.2.15やbind 9.8.2は、コミュニティとしてはサポートを終了しているものの、Red Hat Enterprise Linux 6においてサポートされているため、必ずしも危険、とは言えないというわけです。

余談ですが、バナー情報を収集しているサイトを見ると、httpd 2.2.15 が2.4.6(RHEL7で採用) よりも台数が多いようです。 サポート終了まであと1年切っているので皆さん大変ですね…

Red Hat Enterprise Linux 6は2020年11月30日まで

影響有無の調べ方

多くのディストリビューションでは、共通脆弱性識別子CVEで検索可能なセキュリティポータルが存在します。こちらで検索することで、自分が利用するパッケージに影響があるのか、また修正が適用されるのかを確認することができます。

もし上記のようなCVEから検索可能なポータルが存在しないディストリビューションの場合、自分で脆弱性を評価し、影響有無を確認する必要があります。

とりあえず常に新しいバージョンをコミュニティから落として使えばOK…ではない例

新しいもの好きの方は、コミュニティサポートあるんだし常に新しいバージョンを使えばOK!と思うかもしれません。

コミュニティからリリースされたパッケージは、多くの商用ディストリビューションではサポート契約対象外になってしまいます。 対象外になることで、運用中に動作不具合が出てきても、サポート契約に基づいた問い合わせを行えず、自力で解決する必要があります。

一方で非商用のディストリビューションを使っている場合は、そもそもサポートも無いため、コミュニティリリースを使用しても、動作の確認が無いことを除けば問題ありません。 むしろ、ディストリビューションのコミュニティが修正を反映させるより前に適用できることを考えるとよりセキュアとも考えられます。

おわりに

はじめに、に書いたような質問を度々受けたたため、改めて整理して書き起こしてみました。

パッケージサポートを正しく理解しないと、不必要にも関わらずパッケージをmakeする運用が発生したり、不具合発生時に本来受けられるはずのサポートが受けられないなど、悲しいことになってしまいます。

この話は実際に脆弱性対応を行う運用エンジニアだけではなく、システム構築エンジニア、パッケージバージョン等を参考にセキュリティを評価するセキュリティ監査・コンサル系エンジニアなどなど、多くの人に理解頂ければと思います。

Advent Calender 2019

この記事は岩手県立大学 Advent Calendar 2019の10日目の記事です。

Ansibleもくもく会 (サーバ編 & NW編)2019.08に参加した

明日も仕事なので簡単に…

ansible-users.connpass.com

やったこと

github.com

Section1の演習1.1~1.5途中まで

新たに理解できたこと

  • Ad-hocコマンド+Pingモジュールで簡単に疎通確認ができること

  • モジュール一覧を公式ドキュメントに行かずとも、ansible-docコマンドでコマンドライン上で調査できること

  • 特定タスクが実行された時の追加タスク実行はハンドラーを利用すること Intro to Playbooks — Ansible Documentation

    • 条件分岐だからwhen…?でもタスクがSuccessだった時ってどう書けばいいの…って1か月ぐらい悩んでました。

感想

  • 環境が整った状態でハンズオン形式でもくもくできるので、短い時間で理解がしやすい
  • 質問コーナーがGoogleドキュメントで複数人で書き込めるから、いろんな人の経験談が記載されたりしてためになる

Next

  • 自分のローカル環境で教材の続きを進めたい
  • 各社の活用事例とか参考にしつつ仕事で提案とか導入していって楽していきたい、運用ミスを少なくしたい

「インフラCI 実践ガイド」うまく動かないところメモ書き

本当は著者のサンプルプログラムにプルリクエストすればよいのだけれど、ちょっと自信が無いので読み終わってから再確認する。

新しく見つかったものがあれば随時追加する。

書籍

www.shoeisha.co.jp

演習環境

# cat /etc/redhat-release
CentOS Linux release 7.6.1810 (Core)

Chapter 3

3.5.4 GitLab/GitLab Runnerのインストールと設定

事象

PlaybookのInstall GitLab Runnerタスクが失敗する

原因

Package gitlab-runner-10.5.0-1.x86_64.rpm is not signed

対応

Install GitLab Runner タスクで失敗する · Issue #5 · infra-ci-book/gitlab-vagrant-ansible · GitHub

上記IssueどおりにPlaybookを書き換えればOK。

対象ゲストにログインし、--nogpgcheckオプション付きでインストールする。

# cd ~/vagrant/infraci/
# vagrant ssh gitlab-runner
Last login: Wed May  1 06:01:53 2019 from 10.0.2.2
[vagrant@gitlab-runner ~]$ sudo su -
Last login: Wed May  1 06:03:17 UTC 2019 on pts/0
[root@gitlab-runner ~]# yum install --nogpgcheck gitlab-runner-10.5.0-1
[root@gitlab-runner ~]# exit
logout
[vagrant@gitlab-runner ~]$ exit
logout
Connection to 127.0.0.1 closed.

その後、Playbookを再実行することで構築完了。

Chapter 4

4.1.2 パイプラインの実行

事象

パイプラインUnit_Package# docker build . -t ${CONTAINER_IMAGE_PATH}が失敗する。

$ docker build . -t ${CONTAINER_IMAGE_PATH}
Sending build context to Docker daemon  715.8kB

Step 1/7 : FROM centos:7
 ---> 9f38484d220f
Step 2/7 : ENV container docker
 ---> Using cache
 ---> acc8b01632ab
Step 3/7 : ENV ANSIBLE_VERSION 2.4.2.0
 ---> Using cache
 ---> 702982ebf92d
Step 4/7 : ENV ANSIBLE_LINT_VERSION 3.4.21
 ---> Using cache
 ---> a81864d9a447
Step 5/7 : COPY ./ ./
 ---> 2c24a9e9b7b0
Step 6/7 : RUN (cd /lib/systemd/system/sysinit.target.wants/; for i in *; do [ $i ==      systemd-tmpfiles-setup.service ] || rm -f $i; done);     rm -f /lib/systemd/system/multi-user.target.wants/*;    rm -f /etc/systemd/system/*.wants/*;    rm -f /lib/systemd/system/local-fs.target.wants/*;     rm -f /lib/systemd/system/sockets.target.wants/*udev*;     rm -f /lib/systemd/system/sockets.target.wants/*initctl*;     rm -f /lib/systemd/system/basic.target.wants/*;    rm -f /lib/systemd/system/anaconda.target.wants/*;    yum install -y epel-release &&     yum install -y git &&     yum install -y ansible-${ANSIBLE_VERSION:?} &&     yum install -y ansible-lint-${ANSIBLE_LINT_VERSION:?} &&     yum clean all
 ---> Running in ace833a25437

(中略)

Loaded plugins: fastestmirror, ovl
Loading mirror speeds from cached hostfile
 * base: ty1.mirror.newmediaexpress.com
 * epel: www.ftp.ne.jp
 * extras: ty1.mirror.newmediaexpress.com
 * updates: ty1.mirror.newmediaexpress.com
No package ansible-lint-3.4.21 available.
Error: Nothing to do
The command '/bin/sh -c (cd /lib/systemd/system/sysinit.target.wants/; for i in *; do [ $i ==      systemd-tmpfiles-setup.service ] || rm -f $i; done);     rm -f /lib/systemd/system/multi-user.target.wants/*;    rm -f /etc/systemd/system/*.wants/*;    rm -f /lib/systemd/system/local-fs.target.wants/*;     rm -f /lib/systemd/system/sockets.target.wants/*udev*;     rm -f /lib/systemd/system/sockets.target.wants/*initctl*;     rm -f /lib/systemd/system/basic.target.wants/*;    rm -f /lib/systemd/system/anaconda.target.wants/*;    yum install -y epel-release &&     yum install -y git &&     yum install -y ansible-${ANSIBLE_VERSION:?} &&     yum install -y ansible-lint-${ANSIBLE_LINT_VERSION:?} &&     yum clean all' returned a non-zero code: 1
ERROR: Job failed: exit code 1

原因

No package ansible-lint-3.4.21 available.

対応

有効なansible-lintパッケージバージョンを探し、Dockerfileを書き換える。

# yum --showduplicates search ansible-lint
読み込んだプラグイン:fastestmirror
Loading mirror speeds from cached hostfile
 * base: ty1.mirror.newmediaexpress.com
 * epel: www.ftp.ne.jp
 * extras: ty1.mirror.newmediaexpress.com
 * updates: ty1.mirror.newmediaexpress.com
========================================================== N/S matched: ansible-lint ===========================================================
ansible-lint-3.5.1-1.el7.noarch : Best practices checker for Ansible

  Name and summary matches only, use "search all" for everything.

現時点では3.5.1が有効なので、下記2ファイルの変数を3.4.21から書き換える。

  • ketchup-vagrant-ansible/Dockerfile
  • ketchup-vagrant-ansible/flexible_artifacts/locust/Dockerfile
- ENV ANSIBLE_LINT_VERSION 3.4.21
+ ENV ANSIBLE_LINT_VERSION 3.5.1

更新日

2019/5/1 Chapter 3 / Chapter 4を追加

1024

この記事は岩手県立大学 Advent Calendar 2018の11日目の記事です。

qiita.com

今日は書けない…と嘆かれてるのを見たため、仕事終わりの電車の中で書いてます。

1024

1024 は 210 です。

2進数では 0100 0000 0000

16進数では 0x0400 です。

皆さんご存知のように、コンピュータ界隈では大変きりの良い美しい数字です。

1GB と 1GiB

一般的に、

1GB は 109 = 1,000,000,000 B

1GiB は 230 = 1,073,741,824 B

を指しますが、世の中これらを区別せずに、1GBという表記する製品があります。

500GiBのボリュームをストレージから切り出したいとき、ストレージの管理ツールではGB指定となっていて、ついうっかり500GBで切り出ししまうと、約465GiBしか利用できず35GiBぐらい足りないという事象が発生します。

さらにややこしいことに、500GBで切り出した465GiBの領域をマウントすると、465GBと表示するOSが存在します。

これらのことから、各製品の仕様を十分に確認してからボリュームに設定する値を決定してあげないといけません…。

ただ、パブリッククラウドの利用が広がる昨今、パブリッククラウドではダウンタイム無しでディスク領域を拡張させる機能が備わっており、足りなけりゃ足せば良かったりするので、そんなこまけぇこたぁいいんだよ!って感じではあります。

そもそも普通のストレージも、作成済みのボリュームサイズを後から拡張する機能も備わっているものがあるため、こまけぇこたぁ(

本題

さて、前置きはここまでで、この記事は結婚エントリだったりするわけです。

既に各所で報告しているように、私は10月24日に大学時代からお付き合いしている一般女性の方と結婚しました。

www.instagram.com

入籍当日、最終的に39度の熱暴走をしながら役所に行くなどアクシデントもありましたが、無事提出できホッとしてます。

入籍から早1ヶ月半たっていますが、1年以上同棲していたので大きく変化があったとは感じてません。 お金に対する意識は少し変わったぐらい。

また、多くの方からたくさんのお祝いをいただきました。 妻も大変喜んでおります。 まだまだ受け付けておりますので、皆さんの熱いプレゼント、お待ちしております。

https://www.amazon.jp/gp/registry/wishlist/3B5DDM62LR3JN

昨年以上に勢いが無く寂しいIPUアドベントカレンダー、明日はだれが書くのでしょうか。