好きをお勧め、興味をお報せ（ebiosブログ）

ごきげんよう。

バッファローの古いモデルのルーターから新しい機種に買い替え

今まではバッファローの古いモデルのルーターだったが、Wi-Fi6対応していない上にセキュリティがWEPだったことから慌てて新しい機種を探すことになった。
購入したのはこれ。
バッファロー WiFi 無線LAN ルーター Wi-Fi6 11ax AX1800 1201+573Mbps Easy Mesh 対応無線LANセット (WSR-1800AX4S/NWH（単品）)

バッファローWi-Fi6ルーターWSR-1800AX4Sとは

詳細はバッファローの製品サイトを閲覧してもらうとして、主要なところを箇条書。
Wi-Fi6対応。5GHz最大速度1201Mbpsの最新規格IEEE 802.11axに対応
周波数範囲(チャンネル):2.4GHz / 5GHz:　両バンドに対応
複数端末の同時通信を可能にする「MU-MIMO」に対応。
Wi-Fiセキュリティーの新規格「WPA3 Personal」に対応。互換モードで既存のWPA2対応端末との接続も可能

バッファローWi-Fi6ルーターWSR-1800AX4Sの設定難易度

実際に設定することになったが、役に立ったのは製品に付属の取扱説明書でもバッファローの公式サイトでもなく、Amazonのユーザーレビューだった。
背面のスイッチが２つありそれぞれ（AUTO、MANUAL）と（ROUTER、AP、WB）を選ぶ。
取扱説明書でもバッファローの公式サイトでもスイッチの設定と電源接続とLAN接続だけで良い感じに説明されているが、実際には問題が起こりAmazonのユーザーレビューでは上手く行かずに諦めた人もチラホラ見られた。一方で上手くいく設定を独自に探して正解にたどり着いたユーザーもいて解説してくれていた。その解説に納得したこともあり参考にしつつ起こった問題ごとに対応をしていくことになった。解説してくれていたユーザーには役に立ったを押しておいた。

環境と無線LAN(Wi-Fi）利用端末

光回線のモデムにバッファローWi-Fi6ルーターWSR-1800AX4Sを接続し、無線LAN(Wi-Fi）が利用できるようにする。無線LAN(Wi-Fi）を利用するのはchromebook、スマートフォン（Andoroid）、NintendoSwitch、AmazonFire7、KindleWhitepaper。

バッファローWi-Fi6ルーターWSR-1800AX4Sの背面のスイッチ設定

いろいろ試したが、結局はMANUAL、ROUTERの設定で前面のランプの状態がPOWER/WIRELESS/INTERNET/ROUTERすべて緑で正常となった。（AUTO、MANUAL）のAUTOは取扱説明書では設定するように記載されているが、失敗例がAmazonのユーザーレビューに乗っていることもあり必ずしも上手くいくわけではないと理解してほしい。

バッファローWi-Fi6ルーターの設定画面での変更

バッファローWi-Fi6ルーターに繋いだPCから192.168.11.1をブラウザで参照するとバッファローWi-Fi6ルーターの設定画面にログインできる。そこで一箇所設定を変更した。変更したのはInternetのIPアドレス取得方法。「インターネット＠スタートを行う」から「DHCPサーバーからIPアドレスを自動取得」に変更した。ここの設定項目は環境によって正解が変わる部分なのでよく確認してほしい。

利用端末のWifi設定

chromebookのWifi設定は5GHzのWPA3にあっさり接続できた。問題なし。
スマートフォン（Andoroid）はWifi設定で動作が不安定になった。原因不明。再起動を何度か行ったあと5GHzのWPA3に接続できた。その後は問題なし。
Nintendo SwitchはIEEE 802.11 a/b/g/n/acに準拠。IEEE802.11ax（Wi-Fi 6）にもWPA3に対応していない。2.4GHzのWPA2（AES）があるのでそれに接続。問題なし。
AmazonFire7（第5世代）もIEEE802.11ax（Wi-Fi 6）にもWPA3に対応していない。2.4GHzのWPA2（AES）があるのでそれに接続。問題なし。
KindleWhitepaper（第7世代）もIEEE802.11ax（Wi-Fi 6）にもWPA3に対応していない。2.4GHzのWPA2（AES）があるのでそれに接続。繋がらずエラー。

KindleWhitepaperが接続できなかった理由と解決方法

解説しているサイトがあったので、そちらを紹介。
Amazon製品が5GHz帯Wi-Fiにつながらない時の対処方法（Fireタブ・Fire TV・Echoなど）
今回対象となるAmazon製品が古いので対処は少し違うが、根幹のところは説明されている。ざっくり言えば周波数帯の問題だ。2.4GHzのWPA2（AES）に繋ぎたいので設定も2.4GHz（11ax/n/g/b）の基本設定の倍速モードの帯域を「自動選択（20/40 MHz）」に変更。

その後にKindleWhitepaperを再起動後に2.4GHzのWPA2（AES）に接続できた。問題なし。

回線速度チェック

スマートフォンでGoogleのインターネット速度テストを行った。

満足できる速度が出るようになった。

ルーター選びの注意点

ルーター選びの注意点をいくつか。
・セキュリティがWEPの場合は急いで設定かルーターを変える
・利用する端末が対応している規格を確認し、その規格に対応しているルーターを探す
・複数端末を同時に利用する場合、同時通信を可能とするルーターを探す
・中古のルーターは避ける
・中華のルーターは避ける
　→中国製の安価なルーターに不審なバックドアが存在、積極的に悪用しようとする試みも
　（記事にあるメーカーのルーターはAmazonで販売しているので注意）

感想

速度は低速から高速に。セキュリティは脆弱から強固になった。wifi6やWPA3に対応している端末を持っていてもルーターが対応していないと低速、脆弱になってしまうので、古いルーターの人は確認したほうが良い。個人的には痛い目にあう前に対応ができて快適になったので本当に良かった。

ごきげんよう。

上司から『Excelの結果は全部印刷して電卓検算しろ！』と言われた…しかしシートを見たら上司の手法が正しいと理解した話

上司から『Excelの結果は全部印刷して電卓検算しろ！』と言われた…しかしシートを見たら上司の手法が正しいと理解した話

RTので思い出したんだけど。
上司から「エクセルの結果は全部印刷して電卓検算しろ！」って言われたのね。
ため息出たけど、前任者から引き継いだエクセルのシートは関数ぶっこわれまくってた。
…上司が正しいわ。
この会社では、上司の運用が正しいわ。
まだ人類にエクセルは早かった。

— せいほうけい📛 (@sehoke_p) December 2, 2020

Excelに限らないが、結果というのは、確認項目が全てテスト済みで問題なしになって初めて正しいと判断できる。とはいえ、Excelの結果確認方法が印刷して電卓検算というのは、あまりお勧めできない。テスト用のデータを幾つか用意して、正しい結果になることを確認するような形が望ましいだろう。

プログラムは思った通りに動かない

プログラムは思った通りに動かない。これはよく言われる話だ。プログラムは書いた通りに動く。これも良く言われる話だ。しかし現実は厳しく、プログラムは書いた通りに動こうとするが、環境によって挙動が変わるが正解だ。プログラムだけではなく、動作環境まで管理してやらなければ思った通りには動かない。パッチのバージョンアップによって挙動が変わるなんて話はよくあることだ。

疑う気持ちと確認する手間

自分で作ったものも含めて、正常動作するかどうかは常に疑う気持ちが必要だ。そして確認する手間を惜しんではならない。最終的に大きな間違いとなって問題になるよりは安いコストになるはずだ。

ごきげんよう。

Wake On LANでWindows10からCentOS8を起動

Wake On LAN（WOL）で「マジックパケット」方式でWindows10から同一LAN内のCentOS8を起動できるようにする。

環境

起動する側：
Windows 10 Home バージョン1909

起動される側：
CentOS Linux release 8.2.2004 (Core)
　BIOS　MSI製マザーボードA78M-E35

起動される側のBIOSの設定

MSI製マザーボードでのWake On LAN(WOL)の設定方法について
MSI製マザーボードA78M-E35だったので、その設定。
Advanced→Power Management Settings内にある「EuP 2013」をdisabled（無効）に設定（デフォルトはdisabled）
Advanced→Wake Up Event Setup内にある「Resume By PCI-E Device」をenable（有効）に設定（デフォルトはdisabled）

起動される側のCentOS8の設定を確認

Wake on LANが使える設定にするために必要なのは「Wake-on」の項目設定を「g」にすること。

# dnf install ethtool

Ethtool は、Network Interface Cards (NICs) 設定の際のユーティリティです。このユーティリティを使うと、多くのネットワークデバイス、特にイーサネットデバイスのスピードやポート、オートネゴシエーション、PCI の場所、チェックサムオフロードといった設定のクエリや変更が可能になります。

最初から入っていたので、CentOS8の場合は省いてよい。

# ifconfig

対象となるイーサネットデバイスのラベル名を調べるために実行

# ethtool enp1s0

「enp1s0」は環境ごとにifconfigで調べて該当するイーサネットデバイスのラベル名を指定する

Settings for enp1s0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000033 (51)
drv probe ifdown ifup
Link detected: yes

「Wake-on」の項目設定は「g」ではなく「d」なので、これを「g」にする必要がある。

起動される側のCentOS8の設定を変更

# ethtool -s enp1s0 wol g

一度限りであればこれで「Wake-on」の項目設定は「g」に変更できる。
しかし再起動の度に実行する必要があるので、再起動後もWake on LANを有効にするため、以下の設定を行う。

# vi /etc/rc.d/rc.local

ファイルの内容はコメント以外は「touch /var/lock/subsys/local」だけ。新たに「/sbin/ethtool -s enp1s0 wol g」を追加する

touch /var/lock/subsys/local
/sbin/ethtool -s enp1s0 wol g

# chmod +x /etc/rc.d/rc.local

権限を変更。これで「ethtool -s enp1s0 wol g」が自動で設定される。

起動する側のWindows1０にWake on LAN 対応PCの起動ツールをインストール

Wake on LAN for Windows
ホスト名、IPアドレス、MACアドレスから、Wake on LANの対象とするPCを検索できる。IPアドレスがあればMACアドレスも取得できるので、起動される側のCentOS8でMACアドレスを調べる必要はない。

起動する側のWindows1０からマジックパケットを送信

Wake on LAN 対応PCの起動ツールでCentOS8にマジックパケットを送信

「起動」タグが点灯し、実際にCentOS8の起動が出来た。

ごきげんよう。

クィックスタート: Compose と WordPress

クィックスタート: Compose と WordPress
Docker Compose を使った WordPress の設定と実行をする。

環境

CentOS Linux release 8.2.2004 (Core)
Docker version 19.03.13, build 4484c46d9d

Docker Compose のインストール

Docker Compose のインストール
Linux においては GitHub 上の Compose リポジトリのリリースページ から Docker Compose のバイナリをダウンロードします。

# curl -L "https://github.com/docker/compose/releases/download/1.27.4/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

今日（2020-11-06）現在でGitHub 上の Compose リポジトリが1.27.4だったので、1.27.4を指定している。

% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 651 100 651 0 0 10850 0 --:--:-- --:--:-- --:--:-- 10850
100 11.6M 100 11.6M 0 0 4932k 0 0:00:02 0:00:02 --:--:-- 8008k

# chmod +x /usr/local/bin/docker-compose

プロジェクトの定義

プロジェクトディレクトリを作成し、プロジェクトディレクトリに移動する。
そのディレクトリをたとえば my_wordpress としていた場合、以下のようになる。

# cd my_wordpress

docker-compose.yml ファイルを生成

docker-compose.yml ファイルを生成する。

version: '3'

services:
db:
image: mysql:5.7
volumes:
- db_data:/var/lib/mysql
restart: always
environment:
MYSQL_ROOT_PASSWORD: somewordpress
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wordpress

wordpress:
depends_on:
- db
image: wordpress:latest
ports:
- "8000:80"
restart: always
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress
volumes:
db_data:

mysqlのバージョンで躓くことがあるので、mysqlについてはバージョンは指定した方が良い。

プロジェクトの構築

プロジェクトディレクトリ上にて docker-compose up -d を実行

# docker-compose up -d

Creating network "my_wordpress_default" with the default driver
Creating volume "my_wordpress_db_data" with default driver
Pulling db (mysql:5.7)...
5.7: Pulling from library/mysql
bb79b6b2107f: Pull complete
49e22f6fb9f7: Pull complete
842b1255668c: Pull complete
9f48d1f43000: Pull complete
c693f0615bce: Pull complete
8a621b9dbed2: Pull complete
0807d32aef13: Pull complete
f15d42f48bd9: Pull complete
098ceecc0c8d: Pull complete
b6fead9737bc: Pull complete
351d223d3d76: Pull complete
Digest: sha256:4d2b34e99c14edb99cdd95ddad4d9aa7ea3f2c4405ff0c3509a29dc40bcb10ef
Status: Downloaded newer image for mysql:5.7
Pulling wordpress (wordpress:latest)...
latest: Pulling from library/wordpress
bb79b6b2107f: Already exists
80f7a64e4b25: Pull complete
da391f3e81f0: Pull complete
8199ae3052e1: Pull complete
284fd0f314b2: Pull complete
f38db365cd8a: Pull complete
1416a501db13: Pull complete
ab2461348ce4: Pull complete
085f6c1f7281: Pull complete
d5b4ad1cc063: Pull complete
791ee5a4264d: Pull complete
b3544511e544: Pull complete
abf41ac6b39b: Pull complete
b6439c866cc6: Pull complete
2990e7a8854f: Pull complete
14660d5f95a2: Pull complete
b8b0371e52ce: Pull complete
14b4eaf6e3f6: Pull complete
36bf819b74a1: Pull complete
1dcde27b5fe8: Pull complete
Digest: sha256:0364d2f6476244fc73fd521a092a083f4259edf6f56811cd45bb187de4034fdc
Status: Downloaded newer image for wordpress:latest
Creating my_wordpress_db_1 ... done
Creating my_wordpress_wordpress_1 ... done

ウェブ・ブラウザ上での WordPress の起動・・・失敗

ウェブ・ブラウザから http://localhost:8000 にアクセス

「Error establishing a database connection」というWordPressの「データベース接続確立エラー」が出た。

ウェブ・ブラウザ上での WordPress の起動失敗の原因

ホストOSがCentOS8であることが原因。どうも名前解決ができない模様。
解決方法としては①か②の何れか。
①デバイスごとにファイアウォールの設定をする（お勧めしない）
② IPマスカレードの設定をする（お勧め）

①の場合、nmcliコマンドでwordpressとmysqlをデバイス単位でファイアウォールの設定をしてやる。具体的には

# nmcli

enp1s0: 接続済み から プロファイル 1
"Realtek RTL8111/8168/8411"
ethernet (r8169), D8:CB:8A:12:98:1F, hw, mtu 1500
ip4 デフォルト, ip6 デフォルト
inet4 192.168.0.6/24
route4 192.168.0.0/24
route4 0.0.0.0/0
inet6 240f:37:7aa3:1:4cd8:6a49:f36c:d35/64
inet6 fe80::3c4d:980f:ab77:80e3/64
route6 240f:37:7aa3:1::/64
route6 ::/0
route6 fe80::/64
route6 ff00::/8

br-4aef7bc26106: 接続済み から br-4aef7bc26106
"br-4aef7bc26106"
bridge, 02:42:65:2F:2F:33, sw, mtu 1500
inet4 192.168.96.1/20
route4 192.168.96.0/20
inet6 fe80::42:65ff:fe2f:2f33/64
route6 fe80::/64
route6 ff00::/8

docker0: 接続済み から docker0
"docker0"
bridge, 02:42:F2:CB:91:F3, sw, mtu 1500
inet4 172.17.0.1/16
route4 172.17.0.0/16
inet6 fe80::42:f2ff:fecb:91f3/64
route6 fe80::/64

# firewall-cmd --permanent --zone=trusted --change-interface=docker0

success

# firewall-cmd --permanent --zone=trusted --change-interface=br-4aef7bc26106

success

# firewall-cmd --reload

success
この場合、br-のデバイスが毎回違うIDを生成するので、docker-compose up -d を実行するたびに設定してやる必要があるのでお勧めしない。

② の場合は単純にIPマスカレードの設定を一回するだけだ。お勧め。

# firewall-cmd --add-masquerade --permanent

success

# firewall-cmd --reload

success

ウェブ・ブラウザ上での WordPress の起動・・・成功

ウェブ・ブラウザから http://localhost:8000 にアクセス

無事WordPress の起動に成功した。
失敗した後は一応

# docker-compose down --volumes

でシャットダウンとクリーンアップを行ってから

# docker-compose up -d

で実行しなおしている。なお、起動後しばらくはDB構築でアクセスできないのでしばらく待つ必要がある。

ハマり所はCentOS8

通常なら「クィックスタート: Compose と WordPress」の手順通りやれば簡単にWordPress の起動まで成功するのだが、今回はホストOSがCentOS8という所でハマった形になった。困ったときはホストOSに何を使っているかもキチンと開示しなければならないという例になったように思う。

ごきげんよう。

期限ギリギリで低品質な物を作り上げる人のスケジュールと期限内に高品質な物を余裕を持って仕上げる人のスケジュール

期限ギリギリで低品質な物を作り上げる人のスケジュールと期限内に高品質な物を余裕を持って仕上げる人のスケジュール

所謂ウォータフォールとアジャフォールの違い。
例えば、ウォータフォールは調査分析の時間が押すと実作業の時間が短くなるという構造的な欠陥がある。アジャフォールの場合は時間が押しても時間を分散しているので、実作業の時間を確保しやすい。
最もアジャフォールにも欠点はある。スケジュールや進捗が把握しづらく、一歩間違えば期限に間に合わないということに繋がりかねない。

最初の想定を超えるか、超えないか

ウォータフォールは上手く行っても最初の想定を超えないことが多い。なぜなら最初に精度の高い完成図を作成をしてから制作をスタートしているためだ。一方で、一度完成図が見えた状態で作成しているので、2度作っているような状態となり、稀に最初の想定を超えた完成度になることもある。良し悪しだが、前者が多いのは確かだ。
アジャフォールの場合は最初の想定がそもそも精度の低い完成図なので、最初の想定を超えるのが普通だ。完成図を含めて一度に作ると言えるので、ウォータフォールの最初の想定を超えた完成度まで届くかは微妙かもしれない。

設計が無ければ制作は出来ない

アジャフォールでは、設計が無くとも制作できると誤解される可能性がある。設計が無い制作は、その場で思い付いた簡単なプロトタイプ止まりだ。それが有用であることは少ない。だが最低限の設計で直ぐに制作してみるのは、それなりに得るものがある場合が多い。最低限の設計で直ぐに制作してみるのはアジャフォールのやり方だ。誤解されなければアジャフォールは有用だが、最低限の設計で直ぐに制作というのは言うほど簡単ではないので、経験と技量が問われる方法ともいえるかもしれない。

自分の希望する形

ウォータフォールとアジャフォールのグラフの中間くらいのものが希望する形だ。最初は調査分析の時間をもっと取ってほしい。ただし、触れたことのない技術が採用されている場合は結局ウォータフォールよりの形になってしまうだろう。

手戻り時のダメージ

ウォータフォールの欠点の最も大きな点は手戻り時のダメージかもしれない。最初のミスが最後に響いて手戻り時という形で時間を奪っていく。一方でアジャフォールは手戻り時のダメージは少ない。最もアジャフォールでも最初期で大きなミスが放置されていれば、ウォータフォールと同様の手戻り時のダメージを負うことは変わらない。アジャフォールはミスに気付く機会の速さと回数の違いで、ウォータフォールより優れていると言えるだろう。

結局は相手次第

ウォータフォールでもアジャフォールでも、顧客の要望がコロコロ変わってしまう場合は結局はどうにもならない。開発手法よりも相手の要望次第な点は辛い所だ。

ごきげんよう。

dockerイメージとDockerfileのFROMを詳しく

dockerのDockerfileについて軽く読み流していたが、きちんと理解するには以下のことを改めて問う必要があるように思った。dockerイメージとは何者で、Dockerfileとは何者で、そのDockerfileに記述されるFROMとは何者か。

Dockerfileとは

Dockerfile のベスト・プラクティス Docker-docs-ja 19.03 ドキュメント

Dockerfile はイメージを構築するために必要な全ての命令を、順番通りに記述したテキストファイルです。

知っている人にはdocker版のMakefileといえば通りが良いかもしれない。
dockerのイメージを構築するための手順を特定の書式と命令群に則り、順番通りに記述したものだ。要するにdockerイメージという環境の構築をテキストファイルに落とし込んだものと言う事になる。

レイヤとは

Dockerfile の命令に相当する読み込み専用のレイヤによって、 Docker イメージは構成されます。それぞれのレイヤは直前のレイヤから変更した差分であり、これらのレイヤは積み重なっています。

唐突に出てきたレイヤとは何か。

FROM ubuntu:18.04
COPY . /app
RUN make /app
CMD python /app/app.py

これらの命令ごとに１つのレイヤを作成します、とある。

イメージを実行し、コンテナを生成すると、元のレイヤ上に新しい 書き込み可能なレイヤ（writable layer） （これが「コンテナ・レイヤ」です）を追加します。実行中のコンテナに対する全ての変更、たとえば新しいファイル書き込み、既存ファイルの編集、ファイルの削除などは、この書き込み可能なコンテナ・レイヤ内に記述されます。

上の例でいえば「ubuntu:18.04」レイヤに「COPY . /app」「RUN make /app」で新しいレイヤを追加、さらに「CMD python /app/app.py」でpython で/app/app.pyが実行されたイメージを作ると言う事になる。「ubuntu:18.04」レイヤに他のレイヤが積み重なったという表現はわかりやすいかもしれない。

build とは

一言で言えば、指定したDockerfile に従ってdockerイメージを構築するコマンドだ。これも知っている人にはdocker版のmakeコマンドと言えば通りがいいかもしれない。

mkdir myproject && cd myproject
echo "hello" > hello
echo -e "FROM busybox\nCOPY /hello /\nRUN cat /hello" > Dockerfile
docker build -t helloapp:v1 .

上記の例でいえば、BusyBoxを使ってをcatで「helloファイル」を表示するイメージを構築するDockerfileを吐き出し、そのDockerfileに従ってdockerイメージを構築している。

Dockerfile のFROMとは

Dockerfile のFROMとは何か。

FROM ubuntu:18.04
COPY . /app
RUN make /app
CMD python /app/app.py

先ほどのこの例においてFROM は 「ubuntu:18.04 の Docker イメージからレイヤを作成」と解説されている。

mkdir myproject && cd myproject
echo "hello" > hello
echo -e "FROM busybox\nCOPY /hello /\nRUN cat /hello" > Dockerfile
docker build -t helloapp:v1 .

こちらの例ではFROM は busyboxが指定されている。もちろん、busyboxもdockerイメージがあり、単にFROM busyboxと指定すれば、latest（最新）のイメージが指定される。

FROM ubuntu:18.04の場合

FROM ubuntu:18.04の場合はどうか。FROM busyboxと「:」の指定が無い場合はlatest（最新）となるが、「:」を付けるとどうなるか。
FROMについて解説をみよう。

FROM <image> [AS <name>]
または
FROM <image>[:<tag>] [AS <name>]
または
FROM <image>[@<digest>] [AS <name>]
オプションとして、新たなビルドステージに対しては名前をつけることができます。 これは FROM 命令の AS name により行います。 この名前は後続の FROM や COPY --from= 命令において利用することができ、このビルドステージにおいてビルドされたイメージを参照します。
tag と digest の設定はオプションです。 これを省略した場合、デフォルトである latest タグが指定されたものとして扱われます。 tag の値に合致するものがなければ、エラーが返されます。

と言う事で、FROM ubuntu:18.04と指定した場合は、ubuntuの18.04タグのイメージが指定されることになる。
具体的にubuntuのDocker Imagesの18.04を見ると、どの様にubuntu:18.04のdockerイメージが作られているのか、Dockerfileをみることができる。

FROM scratch
ADD ubuntu-bionic-core-cloudimg-amd64-root.tar.gz /
中略
RUN mkdir -p /run/systemd && echo 'docker' > /run/systemd/container
CMD ["/bin/bash"]

ベースとなるdockerイメージがないので、FROM scratchで始まっていることに注目してほしい。

公式の推奨FROM

Dockerfile のベスト・プラクティス Docker-docs-ja 19.03 ドキュメントのFROMの説明において、推奨が記載されている。

可能なら常に、イメージの土台には最新の公式イメージを利用します。私たちの推奨は Alpine イメージ です。これは非常にコントロールされながら、容量が小さい（現時点で 5MB 以下） Linux ディストリビューションです。

Alpine イメージとは

完全なパッケージインデックスとわずか5MBのサイズを備えたAlpineLinuxに基づく最小限のDockerイメージ！と謳われているのが、Alpine イメージだ。さらに「他のBusyBoxベースのイメージよりもはるかに完全なパッケージリポジトリにアクセスできます。これにより、Alpine Linuxは、ユーティリティや本番アプリケーションの優れたイメージベースになります。」とのこと。実際にAlpine イメージを採用している例として、先日取り上げたウェブサーバーソフトであるcaddyを挙げてみる。latest（最新）のcaddyのDockerfileをみると「FROM alpine:3.12」から始まっている。alpineは現在「3.12.1, 3.12, 3」をlatestとしている。

まとめで詳しく

dockerイメージとは何者で、Dockerfileとは何者で、そのDockerfileに記述されるFROMとは何者か。
dockerイメージとは指定したDockerfile に従ってbuild コマンドによって構築されたdockerコンテナ用イメージ。
Dockerfileとはdockerイメージを構築するために必要な全ての命令を、順番通りに記述したテキストファイル。
FROMとはDockerfileに記載する土台となるもの。通常はdockerイメージを指定するが、無ければFROM scratchと書く。公式推奨はFROM Alpine。

ごきげんよう。

公式 Chrome OS で Dell Inspiron 14-3452 を Chromebook 化してみた。

公式 Chrome OS で Dell Inspiron 14-3452 を Chromebook 化してみた。

使い道に困っていたノート PC に Chrome OS をインストールしてみました。
オフィシャルの Chrome OS です。Chromium OS ではありません。ましてや CloudReady でもありません

Chrome OSはGoogleの開発した専用OS。Chromium OSはChrome OSのオープンソース開発バージョン。CloudReadyはneverwareがChromiumで構築したオペレーティングシステム。通常Chrome OSを使おうと思うとプリインストールされたマシンを購入する必要がある。

オフィシャルの Chrome OS をインストールするには

オフィシャルのChrome OS をインストールするためには、準備をするための Windows環境
Linux Mint
Rufus
Brunch
shell script
Chrome OS リカバリーイメージ
が必要でした。

Windows環境、Linux Mint、Rufus辺りはLinuxを入れる場合は普通な事なので、Chrome OS独自の作業となる後半部分がちょっとハードルになりそうだ。

Chrome OS なので Android アプリも使うことができます

Chromium OS ではなく Chrome OS なので Android アプリも使うことができます。
64bit のプロセッサに限られてしまいますが、個人的に Android アプリを使うのであれば Android-x86 系を使うより Chrome OS で Android アプリを使ったほうが良い気がしました。

条件に該当するようなマシンが無いので、試すことが出来ないのは残念だが、該当するマシンがあれば試してみる価値はありそうだ。Android アプリをエミュレータ無しで使えることにはそれなりに価値があるだろう。

ごきげんよう。

Caddyとは

Caddyのサイトに行くとデカデカと、そして堂々とこう書かれている。
THE ULTIMATE SERVER
なかなかここまでは断言できないものだ。
Caddyとは初版が2015年4月28日と新しいといえるオープンソースのウェブサーバーだ。 Go言語で記述されており、HTTP機能にはGo標準ライブラリを使用している。また他のウェブサーバーと異なり、HTTPSをデフォルトで使用する。

CentOS8にCaddyを入れずにCaddy起動する

前回CentOS8にNginxを入れずにdockerを利用してNginxを起動したが、同じことをCaddyでやってみる。

環境

前回確認済みだが改めて環境を。
CentOS Linux release 8.2.2004 (Core)
Docker version 19.03.13, build 4484c46d9d

CentOS8にCaddyを入れずにdockerでCaddy起動する

docker のコンテナもイメージも無い状態を確認する。

# docker ps -a
# docker images

Caddy起動する

# docker run --name testcaddy -d -p 8081:80 caddy
# docker ps -a
# docker images

特に何をすることもなく、caddyをPullしてコンテナの起動まで出来た。

Firefoxでhttp://localhost:8081にアクセス

Firefoxでhttp://localhost:8081にアクセスする。8081なのはdocker runで「-p 8081:80」と指定した為だ。

問題なく、Caddyが動いているのが確認できた。
何に躓くことも無く、dockerでのCaddy起動は簡単に終わった。

Caddy設定ファイルとindex.htmlの場所

Caddy起動まで何事も無かったので、Caddyのコンテナに少し触ってCaddy設定ファイルとindex.htmlの場所を確認してみる。

# docker exec -it testcaddy /bin/ash
# cd /etc/caddy
# ls
# cat Caddyfile

# Set this path to your site's directory.
root * /usr/share/caddy
と設定されている。

# cd /usr/share/caddy
# ls
# cat index.html

設定どおり/usr/share/caddyの下にindex.htmlがいることが確認できた。
Caddyをお試しするなら、dockerで行うのが楽で良さそうだ。

ごきげんよう。

CentOS8にNginxを入れずにNginx起動する

CentOS8にNginxを入れずにNginx起動することは可能だ。具体的にはdockerをインストールしてdockerを利用してNginxを起動する。

# nginx -V

CentOS8にはNginxをインストールしていないので、コマンドが見つかりませんでしたのメッセージ。その後にnginx のインストールを促してくるがNo。この状態でdockerをインストールしてdockerを利用してNginxを起動してみる。

CentOS8にdockerをインストール手順についての参照元

docs.docker.comのCentOSにDockerエンジンをインストールするを参考にしようかと思ったが、CentOS7を対象としており、CentOS8向けではなかった。そのため、CentOs8にdockerをインストールを参考にさせてもらいインストールの実施をすることにした。

CentOS8にdockerをインストール（失敗）

手順としては
①CentOSにDockerエンジンをインストールするを参考に、一応古いバージョンのアンインストールを実施

# dnf remove docker docker-client docker-client-latest docker-common docker-latest docker-latest-logrotate docker-logrotate docker-engine

②CentOS Linuxのバージョン確認

# cat /etc/centos-release

CentOS Linux release 8.2.2004 (Core)
③リポジトリの追加 確認

# dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

④リポジトリの確認

# dnf repolist

⑤DockerEngineのインストールを実施（失敗）

# dnf install --nobest docker-ce

CentOS8をインストール直後の状態では、古いバージョンのdockerアンインストールは対象が無かったので「①CentOSにDockerエンジンをインストールするを参考に、一応古いバージョンのアンインストールを実施」は飛ばしてもらって問題ない。

CentOS8にdockerをインストール（成功）

競合するパッケージがあり、DockerEngineのインストールに失敗したので、警告通り競合するパッケージを置きかえるコマンドラインを追加して再度CentOS8にdockerのインストールを実施した
⑤DockerEngineのインストールを実施（成功）

# dnf install --nobest docker-ce --allowerasing

dockerインストールが成功したので
⑥dockerのバージョンを確認

# docker --version

Docker version 19.03.13, build 4484c46d9d
⑦dockerの自動起動と起動設定

# systemctl enable docker
# systemctl start docker

を実施。

dockerを利用してNginxを起動する

⑧dockerを利用してNginxを起動

# docker run --name testnginx -d -p 8080:80 nginx

⑨dockerのコンテナの状態の情報表示

# docker ps -a

docker runでnginxを「testnginx」という名前で<ホスト側のポート>:<コンテナ側のポート>を8080:80で実行している。
docker ps -aでコンテナの状態を表示すると
NAMESが「testnginx」PORTSが「0.0.0.0:8080->80/tcp」と、指定した条件で実行されているのが確認できる。なお後で確認することになるので、CONTAINER IDが「c917cab45486」で実行されていることにも注目しておいてほしい。

Firefoxでhttp://localhost:8080にアクセス

Firefoxでhttp://localhost:8080にアクセスする。8080なのはdocker runで「-p 8080:80」と指定した為だ。

CentOS8にNginxを入れずにdockerを利用してNginx起動することに成功した。

Dockerコンテナ、イメージを削除する

⑩dockerのコンテナの停止

# docker stop c917cab45486

⑪dockerのコンテナを削除

# docker rm c917cab45486

⑫dockerのコンテナの状態の情報表示

# docker ps -a

実行中のコンテナを削除しようとするとエラーとなるので、事前にdocker stopでCONTAINER ID「c917cab45486」を指定して停止している。その後、docker rmで削除してdockerのコンテナが無くなったことをdocker ps -aで確認している。
⑬dockerのイメージの状態の情報表示

# docker images

⑭dockerのイメージを削除

# docker rmi f35646e83998

⑮dockerのイメージの状態の情報表示

# docker images

dockerのコンテナは削除したが、dockerのイメージは残っている。dockerのイメージの情報表示を行い、IMAGE IDを指定してdockerのイメージを削除、再度dockerのイメージの情報表示を行い、dockerのイメージが無くなったことを確認している。

ごきげんよう。

CentOS8のインストール準備

今回はGUIありのサーバーとしてCentOS8のインストールを行う。最初にすることはCentOS Linuxの公式サイトへのアクセスしてダウンロードサイトへ行くこと。
CentOS LinuxのダウンロードサイトからISOファイルをダウンロード
なお、今回はUSBでブートできるようにISOイメージをUSBに書き込んでいる。
Rufus ブート可能なISOイメージファイルをもとにブータブルUSBメモリを簡単に作成
USBをインストール先のサーバー挿入してダウンロードしたCentOS8 ISOイメージを起動。

CentOS8のインストール

ISOイメージを選択してブートしてインストール画面に遷移させる。
その後は難しい設定は特ないので問題はほとんど発生しない。
気を付ける点だけ。
ストレージの設定はメニューより、インストール先を選択するので、書き込み先が既にデータがある状態の場合は削除して書き込むように設定することも出来てしまうので、その辺りは環境によって決めなければならない。

ネットワークの設定

ネットワーク接続をスイッチをしてオンにする
環境に依るが、固定IPが必要であれば手動でlPv4のアドレス、ネットマスク、ゲートウェイ、DNSを設定する。
DHCPで良いなら、自動（DHCP）を選ぶだけで終わりだ。

日本語フォントの設定

CentOS8では日本語表示は出来ても入力ができない。そのため、インストール後に日本語入力のできるフォントを手動で入れる必要がある。
①ターミナルを開いて日本語入力に必要なパッケージをインストール
　# dnf -y install libkkc libkkc-data ibus-kkc
②再起動
③「設定」から「Region & Language」を開く
④入力ソースの「+」ボタンを押す
⑤入力ソースの言語一覧が出てくるので「日本語」を押す
⑥「日本語(かな漢字)」を選択し、「追加」ボタンを押す

⑦入力ソースに「日本語(かな漢字)」追加されたら「日本語」を「-」ボタンで削除し「日本語(かな漢字)」だけにする

リモート接続を可能にするxrdpのインストールと設定

環境（$ cat /etc/redhat-release ）：CentOS Linux release 8.2.2004 (Core)
ターミナルを開く。
①EPELリポジトリをインストール

# dnf install epel-release

②xrdpとtigervnc-serverをインストール

# dnf -y install xrdp tigervnc-server

③xrdpの自動起動と起動の設定

# systemctl enable xrdp
# systemctl start xrdp

④fiwawallの設定

# firewall-cmd --permanent --zone=public --add-port=3389/tcp
# firewall-cmd --reload

Windows10からCentOS8へリモート接続

環境：Windows10
①スタートメニューから「Windowsアクセサリ」の「リモートデスクトップ接続」を選択

②コンピューターにIPアドレスかホスト名、ユーザーにrootか設定済みのユーザー名を入力して「接続」ボタンを選択

③接続できるとリモートデスクトップ画面が開きWindows10からCentOS8の操作が可能になる

今後はWindows10からのリモートデスクトップ接続によって、CentOS8側のモニターは無くとも作業することが出来るようなった。