Ansible Tower 3.8をインストールする
Ansibleもくもく会で「Ansible Tower便利だなー」となったのでRed Hat Developer Programを活用してインストールし、遊んでみます。
商用利用や商用検証などには制約があるので、その場合はライセンスを買うかAWXコミュニティに参加してください。
また、本内容は下記ブログを参考にしています。 zaki-hmkc.hatenablog.com
導入前準備
RHELサーバを構築します。 システム要件は下記を参考にしてください。
内容を見ると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 HatのCDNからダウンロードしてくるようですが、1回数kb/sしか落ちない悲しい時がありました。そんな時はキャンセルして再ダウンロードをするとすぐ落ちてきたのでご参考まで。
インストール設定
ファイルを展開し、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
を選定することとした。
- コンテナ内を弄るつもりがないので運用上UbuntuやCentOSが使いやすいとかもなく、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には厳しい
選手市場が厳しい
プレイ人口がPS4やXBOXと比べると圧倒的に少ないのか、出品数が少ない選手が多々います。 結果として使いたい選手を高値で買う必要や、SBC用の希少な選手を手に入れることができないことがあります。
レートのボーダーが厳しい
Squad Battlesのレートボーダーが高いです。特にエリート帯より上は。1試合あたりに貰えるポイントも変わらないのに、これだけ格差が出てくるとちょっとやる気がなくなります。 詳細はfutbinというコミュニティサイトのランキングを直接見てご確認ください。
情報が少ない
各選手の能力値やアップデート内容については、PS4やXBOXと共通です。 しかし、前述の通り選手市場が大きく異なり相場が一致していません。
選手相場を収集して提供してくれる各コミュニティサイトはPS4やXBOXについては双方収集してくれているのですが、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があればわざわざゲーム専用機のために置き場を用意する必要がなくなります。 GPUもFIFAの場合、”現時点では”そこまでハイスペックなグラボを求められないのがうれしいところです。
ただし、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で検索可能なセキュリティポータルが存在します。こちらで検索することで、自分が利用するパッケージに影響があるのか、また修正が適用されるのかを確認することができます。
Red Hat CVE Database : https://access.redhat.com/security/security-updates/#/cve
Published SUSE Linux security updates by CVE number : https://www.suse.com/security/cve/
Amazon Linux Security Center : https://alas.aws.amazon.com/
Ubuntu CVE Tracker : https://people.canonical.com/~ubuntu-security/cve/
もし上記のようなCVEから検索可能なポータルが存在しないディストリビューションの場合、自分で脆弱性を評価し、影響有無を確認する必要があります。
とりあえず常に新しいバージョンをコミュニティから落として使えばOK…ではない例
新しいもの好きの方は、コミュニティサポートあるんだし常に新しいバージョンを使えばOK!と思うかもしれません。
コミュニティからリリースされたパッケージは、多くの商用ディストリビューションではサポート契約対象外になってしまいます。 対象外になることで、運用中に動作不具合が出てきても、サポート契約に基づいた問い合わせを行えず、自力で解決する必要があります。
一方で非商用のディストリビューションを使っている場合は、そもそもサポートも無いため、コミュニティリリースを使用しても、動作の確認が無いことを除けば問題ありません。 むしろ、ディストリビューションのコミュニティが修正を反映させるより前に適用できることを考えるとよりセキュアとも考えられます。
おわりに
はじめに、に書いたような質問を度々受けたたため、改めて整理して書き起こしてみました。
パッケージサポートを正しく理解しないと、不必要にも関わらずパッケージをmakeする運用が発生したり、不具合発生時に本来受けられるはずのサポートが受けられないなど、悲しいことになってしまいます。
この話は実際に脆弱性対応を行う運用エンジニアだけではなく、システム構築エンジニア、パッケージバージョン等を参考にセキュリティを評価するセキュリティ監査・コンサル系エンジニアなどなど、多くの人に理解頂ければと思います。
Advent Calender 2019
この記事は岩手県立大学 Advent Calendar 2019の10日目の記事です。
Ansibleもくもく会 (サーバ編 & NW編)2019.08に参加した
明日も仕事なので簡単に…
やったこと
Section1の演習1.1~1.5途中まで
新たに理解できたこと
Ad-hocコマンド+Pingモジュールで簡単に疎通確認ができること
SSH疎通確認のためcommandモジュールでとりあえずuname -aやってたの、インベントリだけ用意してAd-hocコマンドでPingモジュール使うだけでよかったのか。。。これならPlaybookの説明すらいらない… #ansiblejp
— 田中ァ (@tanakaxa) 2019年8月13日モジュール一覧を公式ドキュメントに行かずとも、
ansible-doc
コマンドでコマンドライン上で調査できること特定タスクが実行された時の追加タスク実行はハンドラーを利用すること Intro to Playbooks — Ansible Documentation
- 条件分岐だからwhen…?でもタスクがSuccessだった時ってどう書けばいいの…って1か月ぐらい悩んでました。
感想
- 環境が整った状態でハンズオン形式でもくもくできるので、短い時間で理解がしやすい
- 質問コーナーがGoogleドキュメントで複数人で書き込めるから、いろんな人の経験談が記載されたりしてためになる
質問コーナーが複数人で編集可能なdocsになってるのすごく良くて、質問しつつ集中しててもくもくしてるといつの間にか回答来てるし、複数の参加者参加型で回答できるので、いろんな事例が集まったりして面白い。 #ansiblejp
— 田中ァ (@tanakaxa) 2019年8月13日
Next
- 自分のローカル環境で教材の続きを進めたい
- 各社の活用事例とか参考にしつつ仕事で提案とか導入していって楽していきたい、運用ミスを少なくしたい
「インフラCI 実践ガイド」うまく動かないところメモ書き
本当は著者のサンプルプログラムにプルリクエストすればよいのだけれど、ちょっと自信が無いので読み終わってから再確認する。
新しく見つかったものがあれば随時追加する。
書籍
演習環境
# 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から書き換える。
- 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日目の記事です。
今日は書けない…と嘆かれてるのを見たため、仕事終わりの電車の中で書いてます。
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日に大学時代からお付き合いしている一般女性の方と結婚しました。
入籍当日、最終的に39度の熱暴走をしながら役所に行くなどアクシデントもありましたが、無事提出できホッとしてます。
入籍から早1ヶ月半たっていますが、1年以上同棲していたので大きく変化があったとは感じてません。 お金に対する意識は少し変わったぐらい。
また、多くの方からたくさんのお祝いをいただきました。 妻も大変喜んでおります。 まだまだ受け付けておりますので、皆さんの熱いプレゼント、お待ちしております。
https://www.amazon.jp/gp/registry/wishlist/3B5DDM62LR3JN
昨年以上に勢いが無く寂しいIPUアドベントカレンダー、明日はだれが書くのでしょうか。