投稿

Docker Desktopの変わりにコマンドでDockerを利用 ( Dockerfile / docker-compose.yaml )

記事の更新日: 2026/08/25 1.概要 Docker Desktopの有料化は2021年9月から実施されています。DockerはLinux kernelの機能を利用して実現されており、Linuxのない世界では動作しません。WindowsやMacはLinuxのない世界です。WindowsはWSLの仮想環境でLinuxを利用できますが、WindowsやMacでDockerを利用するには、Docker Desktopを利用するのが一般的と認識しています。 私はLinuxをネイティブ環境で利用しているので、Dockerを利用するためにDocker Desktopを利用する必要性はありません。Dockerをコマンドで利用します。このことに関して、記述をします。 2.詳細 参考資料を参照すると、「Docker Desktop は、CLI を使って主要な処理を行わなくても、コンテナ、アプリケーション、イメージをマシン上から直接管理できる」と記述されています。逆に捉えると、CLIを利用するとDocker Desktopは利用しなくても良いことになります。 DockerはLinuxのkernel機能を利用していることを理解しておくことが重要です。従ってDocker実行環境ではLinuxのOSが起動していることになります。Macの場合はLinuxを仮想環境で動かしてその上でdockerを動作させていると理解しています。Windowsも同じですが、WSL環境はubuntuなので、これを利用してdockerを動かせます。 Docker Desktopは形の上では仮想環境にDockerを導入したものだと思っています。GUIベースで利用できるので便利なので利用する方が増えているのでしょう。利用者にはLinuxの存在を意識させないものとなっていると思っています。 私はubuntu上にDockerを導入して直接利用しているので、Docker Desktopを利用したことはありません。Dockerを利用する上で理解しておくことが2つあります。1つはcontainerを構成するDockerfile、もう1つはcontainer実行環境を提供するdocker-composeです。両者を理解するとCLIでdockerを利用できます。CLI環境になれるととても便利であると思っています。 3.所見 D...

lsblkの出力がubuntu/LinuxMintで変わりました

記事の更新日: 2026/09/05 1.概要 この記事は2024年の記事です。丁度、ubuntu 22.04に本格移行をする必要に迫られて、作業を開始した時にlsblkの出力結果がubuntu 20.04と異なることがわかり、運用しているshellの見直しをした時に記述しました。ubuntu 22.04移行でがっかりした時の気持ちを残したいと思って、記事を備忘録に残すことにしました。 ubuntuのVersion移行は定期的な行事と同じです。何らかの問題が普通に起きてしまいます。特に導入手順をshellを利用した自動化を勧めていると、細かい設定がとても気になります。設定が変更されることで自動化したshellの見直しが必要になるためです。 今回はlsblkのコマンドの実行結果表示が1項目増加したために、その結果を利用した自動化shellで問題が起きてしまいました。定期的な行事とは言えますが、shellを見直すことは案外辛い作業です。 ubuntu-20.04からubuntu-22.04へ移行をするための試験PCを準備して環境構築をしています。ubuntu-20.04で利用していたlsblkコマンドを利用していたshellが正しく実行されないので調べてみると、lsblkの表示項目が1項目増えていました。その内容に関して記述します。 私の評価は以下の通りです。 (1) ubuntu 22.04からlsblkにFSVER項目が追加、使われてない気がします。 (2) 本当に必要な項目ならば、ubuntu 20.04等の過去バージョンも揃えてほしい。 2.詳細 lsblk利用してDiskのUUIDを調べていますが、ubuntu-20.04とubuntu-22.04では、FSVER項目が追加されていることに気が付きました。ヘッダー情報を記述します。 具体的なコマンドは以下の通りです。 $ lsblk -f (a) ubuntu-22.04 NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS (b) ubuntu-20.04 NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT FSVERが追加されてことで、UUIDの場所がズレてしまい処理が正しく実行されませんでした。FSVE...

ファイル作成を検知するinotify-toolsを試しました

記事の更新日: 2026/09/07 1.概要 ubuntu環境でファイルが作成されたことを検知する仕組みとしてinotify-toolsをネットで見つけて、検証しました。まず、どのようにして検知できるのかをLocalPCで確かめました。次に、Google Driveをgoogle-drive-ocumlfuseでmount後、動作するか試験しました。この内容を記述します。 私の評価は以下の通りです。 (1) LocalPC環境ではinotyfy-toolsは期待通りに動作します (2) google-drive-ocumlfuseのmount環境では単体ファイルのみ動作で期待はずれです (3) 従って、inotify-toolsをGoogle Drive上で活用することは断念しました (4) この機能とコピー機能を代替できるツールとしてrcloneがあります 2.詳細 inotify-toolsには、inotifywaitとinotifywatchが提供されますが、今回はinotifywaitに着目します (a) インストール 参考資料に沿って、インストールします。環境はubuntu-20.04.6です。 sudo apt install inotify-tools (b) ファイル検知設定 ローカルに検知用のディレクトリを作成します mkdir /home/username/share 検知用shell(test.sh)を作成します 今回はファイルが完了したら検知する設定にしました。 inotifywait -m /home/username/share -e close_write |     while read -r directory action file     do         echo "$directory, $action, $file"     done 検知用shell(test.sh)を実行します sh test.sh Setting up watches. Watches established. と表示されて止まります。 (c) ファイル検知試験 別のterminalを開いて、shareディレクトリに入ります。 cd /home/u...

uefiBIOSとLegacyBIOSの両方でbootできるmulti boot USB作成

記事の更新:2026/09/01 1.概要 LegacyBIOSとuefiBIOSではブート手順が異なります。PC機器はuefiBIOSに変わっていますが、CSMを選択できる機能があり、LegacyBIOSも現状では利用できます。2つのBoot方式に別々に対応するとUSBデバイスが増加するので何とか1このデバイスで両方をサポートできないかと考えていました。 ubuntuのresucue用途としてusb bootデバイスを作成して、BIOS PCで利用可能になりました。しかし、uefi-BIOSでは利用できないので、BIOSとuefi-BIOSの両方で利用できるmulti boot USBを作成しました。この内容を記述します。 2.詳細 参考資料にある以前作成したmicroSD方式を利用します。 (a) microSDの初期化 (non-uefi BIOS対応PCでの作業) usb変換アダプターにmicroSDを取り付けます。usb bootのubuntu liveCD(20.04.6 desktop)を利用して、起動をしてからgpartdでmicroSDのpartion tableをmsdos形式で初期化します。今回はmulti bootなので少しパーティション構成を変えます。64GBのmicroSDを設定したUSBデバイスを/dev/sddとします。 gpartdで以下のようにパーティションを作成します。 /dev/sdd1  256MB  fat32 /dev/sdd2  50GB   ext4 (b) ubuntu-20.04.6 install usb bootのubuntu liveCD(20.04.6 desktop)からinstallerを起動して、microSDのext領域(/dev/sdd2)にinstallします。bootは/dev/sddを選択します。問題なくインストールできました。 (c) 起動 non-uefi BIOSでusb boot可能なPC(私の場合は古いNotePCを利用)にusb変換アダプターにmicroSDを取り付けて、BIOSの設定をUSBに変更して起動すると、無事に起動します。 (d) Grubの設定 grub.cfgを/dev/sdd1に作成します。 # mount /de...

ディスクの状態を確認するためにsmartctlを利用しました

記事の更新日:2026/09/30 評価を加筆 1.概要 smartctl は、ストレージデバイス(HDDやSSD)の健康状態や S.M.A.R.T. 情報を監視・診断するためのコマンドラインツールです。S.M.A.R.T.を利用すると、使用時間や電源投入回数、温度、不良セクタ数を調べることができます。実際に、ディスクの状態を確認するためにsmartctlを利用しました。その内容を記述します。 私の評価は以下の通りです。 (1) smartctlは標準機能です。ストレージ障害に備えて利用方法を学習しましょう (2) 使い方は簡単ですが、表示内容の理解が難しい (3) 短期的な観察よりも、長期的な視点で観察することを求められる (4) ストレージ運用の経験値を上げることが重要なこと 2.詳細 (1)調査を始めた理由 500GBのディスクがクラッシュのメッセージを出力して、grubによるブートができなくなりました。しかし、不思議なことにfsckを実行するとエラーなし、各パーティション内のファイルも参照できます。パーティションテーブルを再構築して、再度試しても状況は同じになります。この内容に関して記述します。 障害を解析した訳ではないので、詳細に関しては不明瞭な点が多数あります。grubを利用したbootだけがだめになってしまたディスクのようです。別の代替ディスクに交換して、環境を再構築すると問題はなくなりました。つまり、ディスクはクラッシュしていたと言うことですが、gparted, fsck, fdisk, mkfsでエラーにならない故障でした。 fdiskでディスクを調べていて、2048セクター以前の領域はユーザ側で利用できないことに気が付きました。0〜2047セクターなので、2048 * 512 = 1MBの領域です。ここには、パーティションテーブル以外にもbootに必要な情報が保管されています。私はmsdosパーティションテーブルを利用しているので、MBRが存在します。今回の故障はMBRは無事ですが、2047セクター内のmsdosパーティションテーブル以降の場所でクラッシュが起きたようです。ユーザーが普通利用する領域は無事なのでデータディスクとしては使えるようです。 (2)smartctlの調査 S.M.A.R.T.(Self-Monitoring Analysi...

openSSHで脆弱性の大きな問題が発生 ( openSSH / openSSL / SLUBStick )

記事の更新: 2026/08/31 1.概要 openSSHで脆弱性の大きな問題が発生して対応した内容です。既に過去のことになっていますが、openSSHで問題が発生すると影響が大きいので、すぐに修正を適用しましょう。 また、openSSHに関連したツール類の利用に関して試したことを追記しています。色々なことがopenSSHを基盤に実施することができます。参考にしてください。 2.詳細 ubuntu terminalから下記コマンドでsshのVersionを確認します。 ssh -V (a) ubuntu 20.04.6 6月頃の少し古い環境です OpenSSH_8.2p1 Ubuntu-4ubuntu0.11, OpenSSL 1.1.1f  31 Mar 2020 アップデートをしました。 OpenSSH_8.2p1 Ubuntu-4ubuntu0.11, OpenSSL 1.1.1f  31 Mar 2020 このバージョンは過去に修正済みで問題ないようです。 (b) ubuntu 22.04.4 6月頃の少し古い環境です OpenSSH_8.9p1 Ubuntu-3ubuntu0.7, OpenSSL 3.0.2 15 Mar 2022 アップデートをしました。 OpenSSH_8.9p1 Ubuntu-3ubuntu0.10, OpenSSL 3.0.2 15 Mar 2022 (c) ubuntu 24.04 6月頃の少し古い環境です OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.13 30 Jan 2024 アップデートをしました。 OpenSSH_9.6p1 Ubuntu-3ubuntu13.3, OpenSSL 3.0.13 30 Jan 2024 3.所見 OpenSSHは利用されている範囲が広く、使われているOS環境も異なります。修正情報を提供する側も大変ですが、適用する側も間違えないように適用するのは大変です。 4.追加 本件に関連して調べたことや試したことを参考として追記します。 (1) openSSHで脆弱性の大きな問題が発生をWindows11のwslで確認 Windows11のWSL上のopenSSH脆弱性対応が気になったので試してみました。 まず、Windows updat...

jenkinsをdocker環境で起動

記事の更新日:2026/09/30 評価を加筆 1.概要 CI/CDを支えるツールで日本製品といえばjenkinsです。jenkinsの環境構築は様々なインターフェイスを準備するために手間が必要で面倒でした。しかし、jenkinsをdocker環境で起動すると手間は大幅に改善されます。物理環境や仮想環境に導入して保守をするよりもDocker環境を構築して運用する方が楽になると考えます。その内容を記述します。 私の評価は以下の通りです。 (1) 処理の自動化は作業効率を向上します、Jenkinsは効率化ツールです (2) Dockerのコンテナを利用することで導入を手間を削減できます (3) まず、評価利用することです、改善の第一歩です (4) 開発者全員がメリットあると感じることが重要です 2.詳細 参考資料に従って、jenkins/jenkins:ltsを利用します。jenkinsにもubuntuの用にLTS(Long-Term Support:長期サポート版)がありました。2年間は利用できるので良い選択肢です。 Docker Compose with Jenkinsにdocker-compose.ymlが記述されています。 今回は必要最低限の構成で導入します。 (a) docker-compose.yml version "3" services:   jenkins:     image: jenkins/jenkins:lts     ports:       - "8080:8080" (b) 起動 $ docker-compose up -d で起動します。 (c) ブラウザから接続 Firefoxにて、http://localhost:8080 で接続します。 Unlock Jenkinsが表示され、Administrator passwordを要求されます。 docker-compose logs とterminalで入力をして、 Please use the followin password to proceed to installationの下に記述されている文字列をコピー&ペーストでFirefoxの入力エリアに入力します Customaize Jenkinsでは、...