わざわざShellに石油会社の画像を使う理由は、 こないだ東京証券取引所を破壊した「石原さとみショック」の原因たる << GS社員 >> というTwitterのトレンドを見たとき、 小学５年から石原さとみを追っかけてきた自分ももれなく「ガソリンスタンド」を思い浮かべたからです。 ＊情報圧縮ノートは、今まで文字で説明されていた概念(Knowledge)を１枚のjpegで表現するものです。
わざわざShellに石油会社の画像を使う理由は、 こないだ東京証券取引所を破壊した「石原さとみショック」の原因たる << GS社員 >> というTwitterのトレンドを見たとき、 小学５年から石原さとみを追っかけてきた自分ももれなく「ガソリンスタンド」を思い浮かべたからです。
＊情報圧縮ノートは、今まで文字で説明されていた概念(Knowledge)を１枚のjpegで表現するものです。
はじめに Dockerは多くのIT開発企業で導入されている環境構築を楽にする技術です。 Dockerで作成したコンテナはホスト（自身のPCやAWSなどのクラウド）に対して、ファイルを読み込んだり、また、ホストのサーバーからコンテナへ接続したり、というような関係を持ちます。 それらの関係の条件を指定するために、docker runにオプションを付けて、実行します。 今回はコンテナとホストとの関係の条件付けのためのオプションを紹介します。 今回紹介する内容(docker runコマンドとオプション) コンテナからホストのファイルに接続できるようにする (docker run -v) ユーザーIDやグループIDの指定する (docker run -u) ホストのポートとコンテナのポートをつなげる (docker run -p) コンテナがアクセスできるCPUやメモリの上限を設定する(docker run --cpus)(docker run --memory) コンテナからホストのファイルに接続できるようにする (docker run -v) ホストのファイルをコンテナの中にも存在するように振舞わせることをマウントと言います。 コンテナは誰かに使ってもらったり、手軽に実行させたりできるように、サイズが小さいことが望ましいので、可能な限りコンテナ自体にファイルを設置しないようにします。 例えば、コードのファイルはホストに置いておき、コンテナからホストのコードのファイルを読み込ませるという場合、コードのファイルをコンテナにマウントさせる、と言います。 docker run -it -v (ホストのパス):(コンテナのパス) (DockerImageの名前 or ID) bash 例) docker run -it -v /Desktop/sample_dir:/new_dir (DockerImageのID) bash => コンテナのnew_dirというディレクトリにホストのDesktopに存在するsample_dirというディレクトリがマウントされます。 (コンテナにnew_dirというディレクトリが存在しない場合は、コンテナにnew_dirというディレクトリが自動で作成されます。) ユーザーIDやグループIDの指定する (docker run -u) ホストのファイルをコンテナでマウントさせる場合、ユーザーIDやグループIDを指定しないと、コンテナがルート権限を持ってアクセスすることができてしまいます。 ルート権限がコンテナ側にあると、コンテナからホストのファイルを作成したり、編集したり、様々なことができてしまいます。 ルート権限を持たせたくない場合には、ユーザーIDやグループIDを指定して、マウントさせます。 docker run -it -u (ユーザーID):(グループID) 例) docker run -it -u $(id -u):$(id -g) -v /Desktop/sample_dir:/new_dir (DockerImageのID) bash => ユーザーIDとグループIDが指定して、ホストのファイルをマウントしたコンテナが作成される。 ホストのポートとコンテナのポートをつなげる (docker run -p) ポートとはサーバーの中の特定の場所です。 例えば、サーバーに複数のサービスがあった場合、IPアドレスだけではどのサービスに接続するか分からないため、ポートを指定します。 作成したコンテナを一つのWebサービスとする場合、コンテナのポートとホストのポートをつなげる必要があります。 docker run -it -p (ホストのポート):(コンテナのポート) 例) docker run -it -p ３０００:3000 rails bash => railsというDockerImageからコンテナが作成され、railsのデフォルトのポート3000に繋がるため、ホスト側でlocalhost:3000にアクセスするとrailsにアクセスすることができます。 コンテナがアクセスできるCPUやメモリの上限を設定する(docker run --cpus)(docker run --memory) コンテナが動く時、ホストのCPUやメモリを使います。 例えば、一つのコンテナが限界までCPUやメモリを使ってしまった場合、メモリが枯渇してシステム全体が落ちてしまう可能性があります。 そのようなリスクを避けるために、それぞれのコンテナに対して、CPUやメモリの上限設定をします。 docker run -it --cpus (論理コア数) --memory (メモリ容量) 例) docker run -it --cpus 4 --memory 2g ubuntu bash => ubuntuというDockerImageからコンテナが作成され、このコンテナが使えるCPUの論理コアの上限は4つで、メモリの上限は2ギガとなります。 （コンテナのCPUやメモリを確認したい時は、"docker inspect (コンテナID)"を入力します。） ※自身のPCのCPUやメモリが知りたい場合はターミナルに以下の入力をすると確認できます。 sysctl -n hw.logicalcpu_max => CPU（論理コア数） sysctl hw.memsize => メモリ(byte) 参考 Udemy かめれおん講師 「米国AI開発者がゼロから教えるDocker講座」 https://www.udemy.com/share/103aTRAEAdd1pTTHoC/ 有料ですが、初学者の私にも非常に理解しやすかったです。 最後に 本投稿が初学者の復習の一助となればと幸いです。
Dockerは多くのIT開発企業で導入されている環境構築を楽にする技術です。 Dockerで作成したコンテナはホスト（自身のPCやAWSなどのクラウド）に対して、ファイルを読み込んだり、また、ホストのサーバーからコンテナへ接続したり、というような関係を持ちます。 それらの関係の条件を指定するために、docker runにオプションを付けて、実行します。 今回はコンテナとホストとの関係の条件付けのためのオプションを紹介します。
ホストのファイルをコンテナの中にも存在するように振舞わせることをマウントと言います。 コンテナは誰かに使ってもらったり、手軽に実行させたりできるように、サイズが小さいことが望ましいので、可能な限りコンテナ自体にファイルを設置しないようにします。 例えば、コードのファイルはホストに置いておき、コンテナからホストのコードのファイルを読み込ませるという場合、コードのファイルをコンテナにマウントさせる、と言います。
docker run -it -v (ホストのパス):(コンテナのパス) (DockerImageの名前 or ID) bash 例) docker run -it -v /Desktop/sample_dir:/new_dir (DockerImageのID) bash => コンテナのnew_dirというディレクトリにホストのDesktopに存在するsample_dirというディレクトリがマウントされます。 (コンテナにnew_dirというディレクトリが存在しない場合は、コンテナにnew_dirというディレクトリが自動で作成されます。)
ホストのファイルをコンテナでマウントさせる場合、ユーザーIDやグループIDを指定しないと、コンテナがルート権限を持ってアクセスすることができてしまいます。 ルート権限がコンテナ側にあると、コンテナからホストのファイルを作成したり、編集したり、様々なことができてしまいます。 ルート権限を持たせたくない場合には、ユーザーIDやグループIDを指定して、マウントさせます。
docker run -it -u (ユーザーID):(グループID) 例) docker run -it -u $(id -u):$(id -g) -v /Desktop/sample_dir:/new_dir (DockerImageのID) bash => ユーザーIDとグループIDが指定して、ホストのファイルをマウントしたコンテナが作成される。
ポートとはサーバーの中の特定の場所です。 例えば、サーバーに複数のサービスがあった場合、IPアドレスだけではどのサービスに接続するか分からないため、ポートを指定します。 作成したコンテナを一つのWebサービスとする場合、コンテナのポートとホストのポートをつなげる必要があります。
docker run -it -p (ホストのポート):(コンテナのポート) 例) docker run -it -p ３０００:3000 rails bash => railsというDockerImageからコンテナが作成され、railsのデフォルトのポート3000に繋がるため、ホスト側でlocalhost:3000にアクセスするとrailsにアクセスすることができます。
コンテナが動く時、ホストのCPUやメモリを使います。 例えば、一つのコンテナが限界までCPUやメモリを使ってしまった場合、メモリが枯渇してシステム全体が落ちてしまう可能性があります。 そのようなリスクを避けるために、それぞれのコンテナに対して、CPUやメモリの上限設定をします。
docker run -it --cpus (論理コア数) --memory (メモリ容量) 例) docker run -it --cpus 4 --memory 2g ubuntu bash => ubuntuというDockerImageからコンテナが作成され、このコンテナが使えるCPUの論理コアの上限は4つで、メモリの上限は2ギガとなります。 （コンテナのCPUやメモリを確認したい時は、"docker inspect (コンテナID)"を入力します。）
※自身のPCのCPUやメモリが知りたい場合はターミナルに以下の入力をすると確認できます。
Udemy
かめれおん講師 「米国AI開発者がゼロから教えるDocker講座」 https://www.udemy.com/share/103aTRAEAdd1pTTHoC/
かめれおん講師 「米国AI開発者がゼロから教えるDocker講座」
https://www.udemy.com/share/103aTRAEAdd1pTTHoC/
有料ですが、初学者の私にも非常に理解しやすかったです。
本投稿が初学者の復習の一助となればと幸いです。
はじめに 久しぶりにLinux環境を触ったら結構Linuxコマンドを忘れていたので、メモしておきます。 シンボリックリンク シンボリックリンク作成 ln -s 【ファイル名またはディレクトリ名】【リンク名】 ※ 【リンク名】と【ファイル名またはディレクトリ名】が同一の場合は【リンク名】は省略可能 シンボリックリンク削除 unlink 【リンク名】
久しぶりにLinux環境を触ったら結構Linuxコマンドを忘れていたので、メモしておきます。
ln -s 【ファイル名またはディレクトリ名】【リンク名】
※ 【リンク名】と【ファイル名またはディレクトリ名】が同一の場合は【リンク名】は省略可能
unlink 【リンク名】
はじめに 久しぶりにLinux環境を触ったら結構Linuxコマンドを忘れていたので、メモしておきます。 権限変更 chmod 【モード】【ファイル名またはディレクトリ名】 ※ ディレクトリ配下を再帰的に変更する場合は「-R」オプションを使用 ※ モードの説明は下記のページが分かりやすかったです。 https://qiita.com/shisama/items/5f4c4fa768642aad9e06 所有者変更 chown 【ユーザー名】【ファイル名またはディレクトリ名】 ※ ディレクトリ配下を再帰的に変更する場合は「-R」オプションを使用 所有グループ変更 chgrp 【グループ名】【ファイル名またはディレクトリ名】 ※ ディレクトリ配下を再帰的に変更する場合は「-R」オプションを使用
chmod 【モード】【ファイル名またはディレクトリ名】
※ ディレクトリ配下を再帰的に変更する場合は「-R」オプションを使用
※ モードの説明は下記のページが分かりやすかったです。 https://qiita.com/shisama/items/5f4c4fa768642aad9e06
chown 【ユーザー名】【ファイル名またはディレクトリ名】
chgrp 【グループ名】【ファイル名またはディレクトリ名】
はじめに 久しぶりにLinux環境を触ったら結構Linuxコマンドを忘れていたので、メモしておきます。 グループ関連コマンド グループ追加 groupadd 【グループ名】 グループ一覧 cut -d: -f1 /etc/group ユーザーの所属グループを追加 usermod -aG 【グループ名】 【ユーザー名】 ※ -aG：セカンダリーグループを追加 ユーザーの所属グループを変更 usermod -g 【グループ名】 【ユーザー名】 usermod -G 【グループ名】 【ユーザー名】 ※ -g：プライマリーグループを変更 ※ -G：セカンダリーグループを変更 ユーザーのグループ確認 groups 【ユーザー名】 グループ削除 groupdel 【グループ名】
groupadd 【グループ名】
cut -d: -f1 /etc/group
usermod -aG 【グループ名】 【ユーザー名】
※ -aG：セカンダリーグループを追加
usermod -g 【グループ名】 【ユーザー名】 usermod -G 【グループ名】 【ユーザー名】
※ -g：プライマリーグループを変更 ※ -G：セカンダリーグループを変更
groups 【ユーザー名】
groupdel 【グループ名】
passwdコマンド 自身のパスワードを変更する場合 passwd 現在のパスワード、新しいパスワードを聞かれるので入力します。 [~]$ passwd ユーザー XXX のパスワードを変更。 XXX 用にパスワードを変更中 現在の UNIX パスワード： 新しい UNIX パスワードを入力してください: 新しい UNIX パスワードを再入力してください: passwd: パスワードは正しく更新されました 他人のパスワードを変更する場合 ※ 他人のパスワードを変更できるのはスーパーユーザーのみ passwd [ユーザー名] ※ 以後は自身のパスワード変更時と同様
passwd
現在のパスワード、新しいパスワードを聞かれるので入力します。
[~]$ passwd ユーザー XXX のパスワードを変更。 XXX 用にパスワードを変更中 現在の UNIX パスワード： 新しい UNIX パスワードを入力してください: 新しい UNIX パスワードを再入力してください: passwd: パスワードは正しく更新されました
※ 他人のパスワードを変更できるのはスーパーユーザーのみ
passwd [ユーザー名]
※ 以後は自身のパスワード変更時と同様
環境 Fedora 33(beta) x86_64 cronie-1.5.5-4.fc33.x86_64 cronie-anacron-1.5.5-4.fc33.x86_64 logrotate-3.17.0-3.fc33.x86_64 systemd-246.6-3.fc33.x86_64 症状 logrotateを１時間毎に行いたいが、期待された間隔でローテートされない。 再現手順 (1) Fedora 33 (beta)をミニマムでインストール (2) cronie, cronie-anacron , crontabsをインストール (3) rsyslog と logrotate をインストール (4) /etc/logrotate.d/rsyslog の中で /var/log/messages のローテートに関する 設定をログローテートの間隔を１時間毎 (hourly)とする。 (5) 数時間待つ 期待される結果 /var/log/messages などが、１時間毎にローテートされる。 実際の結果 /var/log/messages などが、数時間待ってもローテートされない。 原因 logrotateの起動方法のデフォルトがcronからsystemd-timerに変わったため。 logrotateのデフォルトの動作間隔がdailyであるため。 詳細 昔はlogrotate はcron/anacronから行われてきたが、最近はsystemd-timer を 使ってログのローテートを行う方向にFedoraの開発者は持っていきたいと考えて いるらしい。 かつては logrotateのRPMパッケージには /etc/cron.daily/logrotateが含ま れていたが、 * Wed Nov 21 2018 Alejandro Domínguez Muñoz <adomu@net-c.com> - 3.14.0-5 - add make as a build dependency - replace cron job with a systemd timer unit (#1502085, #1655153) というタイミングで、この設定ファイルが含まれなくなったようだ。 その代わりに /usr/lib/systemd/system/logrotate.timer, logrotate.service が含まれるようになっているので、こちらを有効にする必要が有る。 # systemctl enable logrotate.timer しばらく待ってみるが、１時間毎にログのローテートが実行されない。 その原因は logrotate.timer 内の初期設定にあった。 /usr/lib/systemd/system/logrotate.timer OnCalendar = daily となっているため、一日一回（午前0時過ぎ）にlogrotateが起動されるのが初期設定と なっている。 そのため、logrotate の設定ファイル内に hourly が書かれていても １時間毎にlogrotateが実行されないため、ログのローテートは行われなかった。 修正方法 # cp /usr/lib/systemd/system/logrotate.timer /etc/systemd/system/ # cp /usr/lib/systemd/system/logrotate.service /etc/systemd/system/ # vi /etc/systemd/system/logrotate.timer 修正前: OnCalendar=daily 修正後: OnCalendar=hourly # systemctl daemon-reload # systemctl enable logrotate.timer これで期待される動きとなった。 参考 https://bugzilla.redhat.com/show_bug.cgi?id=1757726
環境 Fedora 33(beta) x86_64 cronie-1.5.5-4.fc33.x86_64 cronie-anacron-1.5.5-4.fc33.x86_64 logrotate-3.17.0-3.fc33.x86_64 systemd-246.6-3.fc33.x86_64
症状 logrotateを１時間毎に行いたいが、期待された間隔でローテートされない。
再現手順 (1) Fedora 33 (beta)をミニマムでインストール (2) cronie, cronie-anacron , crontabsをインストール (3) rsyslog と logrotate をインストール (4) /etc/logrotate.d/rsyslog の中で /var/log/messages のローテートに関する 設定をログローテートの間隔を１時間毎 (hourly)とする。 (5) 数時間待つ
期待される結果 /var/log/messages などが、１時間毎にローテートされる。
実際の結果 /var/log/messages などが、数時間待ってもローテートされない。
原因 logrotateの起動方法のデフォルトがcronからsystemd-timerに変わったため。 logrotateのデフォルトの動作間隔がdailyであるため。
詳細 昔はlogrotate はcron/anacronから行われてきたが、最近はsystemd-timer を 使ってログのローテートを行う方向にFedoraの開発者は持っていきたいと考えて いるらしい。 かつては logrotateのRPMパッケージには /etc/cron.daily/logrotateが含ま れていたが、
* Wed Nov 21 2018 Alejandro Domínguez Muñoz <adomu@net-c.com> - 3.14.0-5 - add make as a build dependency - replace cron job with a systemd timer unit (#1502085, #1655153)
というタイミングで、この設定ファイルが含まれなくなったようだ。 その代わりに /usr/lib/systemd/system/logrotate.timer, logrotate.service が含まれるようになっているので、こちらを有効にする必要が有る。
# systemctl enable logrotate.timer
しばらく待ってみるが、１時間毎にログのローテートが実行されない。 その原因は logrotate.timer 内の初期設定にあった。
/usr/lib/systemd/system/logrotate.timer OnCalendar = daily
となっているため、一日一回（午前0時過ぎ）にlogrotateが起動されるのが初期設定と なっている。 そのため、logrotate の設定ファイル内に hourly が書かれていても １時間毎にlogrotateが実行されないため、ログのローテートは行われなかった。
修正方法
# cp /usr/lib/systemd/system/logrotate.timer /etc/systemd/system/ # cp /usr/lib/systemd/system/logrotate.service /etc/systemd/system/ # vi /etc/systemd/system/logrotate.timer 修正前: OnCalendar=daily 修正後: OnCalendar=hourly # systemctl daemon-reload # systemctl enable logrotate.timer
これで期待される動きとなった。
参考 https://bugzilla.redhat.com/show_bug.cgi?id=1757726
概要 ログイン対象サーバ間違えて内結環境でやる作業を外結環境で実施してしまいそうになったとかあると思います。 そこで その間違いの確率下げるため工夫としてターミナル文字色変更です。 例えば内結環境ターミナルだったら通常通り白、外結環境だったら緑！等設定しておけば環境間違いによる事故の確率を下げれると思います。 設定方法（putty使っているのでputtyだけ。。） https://www.st.ryukoku.ac.jp/security/ssh/win/custom.html#:~:text=%E5%A4%89%E6%9B%B4%E3%81%99%E3%82%8B%E3%81%AB%E3%81%AF%E3%80%81%5B%E3%82%A6%E3%82%A3%E3%83%B3%E3%83%89%E3%82%A6,%E8%89%B2%E3%82%92%E8%A8%AD%E5%AE%9A%E3%81%97%E3%81%BE%E3%81%99%E3%80%82 設定変更で気をつけること 全体文字色を明るい緑にするとlsコマンド等で表示される実行権限あるファイルもデフォルトで明るい緑になっていることあるのでぱっと見で実行権限あるのかないのか色でわかりにくいことあった。 なのでなるべく他で使用されなそうな色を勧めます。。。
ログイン対象サーバ間違えて内結環境でやる作業を外結環境で実施してしまいそうになったとかあると思います。
その間違いの確率下げるため工夫としてターミナル文字色変更です。 例えば内結環境ターミナルだったら通常通り白、外結環境だったら緑！等設定しておけば環境間違いによる事故の確率を下げれると思います。
https://www.st.ryukoku.ac.jp/security/ssh/win/custom.html#:~:text=%E5%A4%89%E6%9B%B4%E3%81%99%E3%82%8B%E3%81%AB%E3%81%AF%E3%80%81%5B%E3%82%A6%E3%82%A3%E3%83%B3%E3%83%89%E3%82%A6,%E8%89%B2%E3%82%92%E8%A8%AD%E5%AE%9A%E3%81%97%E3%81%BE%E3%81%99%E3%80%82
全体文字色を明るい緑にするとlsコマンド等で表示される実行権限あるファイルもデフォルトで明るい緑になっていることあるのでぱっと見で実行権限あるのかないのか色でわかりにくいことあった。 なのでなるべく他で使用されなそうな色を勧めます。。。
シェルスクリプトでLinux→Windowsへデータをコピー 検証環境 ・CentOS Linux release 7.6 ・Windows Server 2019 手順 1. Linuxにsambaクライアントをインストール # sambaクライアントがインストールされているか確認 rpm -q samba-client # sambaクライアントをインストール yum install -y samba-client 2. Windowsに共有フォルダを作成 3. Linuxからsmbclientでアクセスしputコマンドでデータをコピー # sambaでWindowsの共有フォルダにアクセス #「smb: \>」と表示されればアクセス成功 #「exit」でsamba接続終了 smbclient '\\WindowsのIPアドレス\共有フォルダ名' -U ドメイン名\\ユーザー名%パスワード smb: \> put Linuxデータパス Windowsに置くときのファイル名 smb: \> exit 使用例 #! /bin/bash # /var/log配下の.logファイルを全てWindowsの共有フォルダへコピー for filePath in `find /var/log/*.log`; do # -cでputコマンドを送る smbclient '\\WindowsのIPアドレスまたはPC名\共有フォルダ名' -U ユーザー名%パスワード -c "put ${filePath} ${filePath##*/}" >&1 # Linux側のデータが不要の場合は削除する rm -f $filePath done
・CentOS Linux release 7.6 ・Windows Server 2019
1. Linuxにsambaクライアントをインストール
# sambaクライアントがインストールされているか確認 rpm -q samba-client # sambaクライアントをインストール yum install -y samba-client
2. Windowsに共有フォルダを作成 3. Linuxからsmbclientでアクセスしputコマンドでデータをコピー
# sambaでWindowsの共有フォルダにアクセス #「smb: \>」と表示されればアクセス成功 #「exit」でsamba接続終了 smbclient '\\WindowsのIPアドレス\共有フォルダ名' -U ドメイン名\\ユーザー名%パスワード smb: \> put Linuxデータパス Windowsに置くときのファイル名 smb: \> exit
#! /bin/bash # /var/log配下の.logファイルを全てWindowsの共有フォルダへコピー for filePath in `find /var/log/*.log`; do # -cでputコマンドを送る smbclient '\\WindowsのIPアドレスまたはPC名\共有フォルダ名' -U ユーザー名%パスワード -c "put ${filePath} ${filePath##*/}" >&1 # Linux側のデータが不要の場合は削除する rm -f $filePath done
Xウィンドウシステムに関連してよく目にする用語として、Xウィンドウマネージャ、Xサーバ、デスクトップ環境、GTK+などがあります。 「これら一体何なの？」私がLinuxを触り始めたころ、チンプンカンプンでした。 今回、これらの用語を解説したいと思います。正確で漏れのない解説ではなく、初心者に分かりやすい解説をめざしています。より詳しい解説は、各用語ごとにウィキペディアへのリンクを張っていますのでそちらを参照してください。 （注意、筆者の主観が多分に混じっているため、間違っていたらごめんなさい。そして、ご指摘を歓迎します） 「GUI・CUI」 まず最初にGUI(グラフィカル・ユーザ・インターフェース)とCUI(キャラクタユーザインタフェース)の違いをざっくり説明します。 ・CUIは、キーボードとディスプレイしか制御できない上に、アルファベット文字と一般記号しか扱えない。 ・GUIは、好きな図形や絵や文字が表示でき、マウスポインターなど使って直感的な操作ができる。 古いパソコンはCUIしか備えていませんでした。1960代にコンピュータの使い勝手をよくするためにGUIという考え方が登場しました。 主観的には、GUIが普及し始めたのは1990年代、そして、1995年のWindows95で爆発的にGUIが普及したと感じています。 「ウィンドウシステム」 GUIを実現するための仕組みやソフトウェアの総称。特定の資料やソフトウェアを指しているものではありません。 「X Window System(Xウィンドウシステム)」 ウィキペディアによると、 "X Window Systemとは、ビットマップディスプレイ上でウィンドウシステムを提供する表示プロトコルである。リファレンス実装として X.Org Server があり、標準ツールキットとプロトコルを提供し、Unix系オペレーティングシステム (OS) やOpenVMSなどでのグラフィカルユーザインタフェース (GUI) を構築するのに使われる。他の多くの汎用OSにも移植されている。" となっています。 Xウィンドウシステムとは、仕組みや方法をまとめた資料。と、私は解釈しました。 なので、Xウィンドウシステムというソフトウェアは存在しないのですが、それでは解りづらいということでリファレンス実装のソフトウェアが作成されました。元々はリファレンス実装なのですが、他にXウィンドシステムに準拠したソフトウェアが存在しなかったために(以前はXFree86があったが)、このリファレンス実装が事実上の標準になっていると考えると納得がいきます。(狭義では、https://www.x.org/releases/X11R7.7/doc/ の Protocol specifications: 部分。広義では、このURL全体) LinuxのGUI ＝ Xウィンドウシステム は、あながち間違いではありませんが、Linuxをより深く知ろうとするならば、 ・Xサーバ ・Xウィンドウマネージャ ・ウィジェット。ツールキット ・アプリのGUI機能 などのソフトウェアが連携してLinuxのGUIが成り立っていることを意識し、それぞれの役割を理解するべきです。 なお、開発元は、"X Window System"の他に、別名として"X"や"X11"を使うことを求めています。 「X.Org Server(Xサーバ)」 Xウィンドウシステムに準拠したソフトウェア（キーボート、マウスなどからの入力と、ディスプレイへの表示を行うソフトウェア）。 アプリ(ブラウザやオフィースソフトなど)が直接ハードウェアを制御してGUIを実現することもできるのですが、そうしてしまうと、他のアプリがキーボートやマウス、ディスプレイを使えなくなります。そうならないようにXサーバがハードウェアとアプリを仲介をします。 画像や図形をディスプレイに表示するための機能(グラフィックコンテキスト)をアプリに提供するのもXサーバの役割です。ちなみに音(audio)やプリンタはXサーバは関与しません。 ※名称は、"X.Org Server"の他に、"XServer"、"X.Orgサーバー"、"Xサーバー"と表記されている場合を見かけます。また"Xサーバ"と語尾に"ー"が付かないのは"プリンタ"や"メモリ"と同じ表記ゆれです。 「XFree86」 Xウィンドウシステムに準拠したソフトウェア。Xサーバと似た機能を提供していましたが、今ではメンテナンスが終了しています。なのでXウィンドウシステムに準拠したGUIはXサーバのみとなっています。 「Wayland」 Waylandは、Xサーバを置き換える存在です。 XサーバはXウィンドウシステム(X11プロトコル)に準拠しています。しかし、このX11プロトコルの初版リリースは1987年とかなり古く、近年のGPUや高解像度などにそぐわなくなってきています。 Waylandはグラフィクス周りのみに特化しており、Xサーバの全ての機能を置き換えるというわけではありません。 「Xウィンドウマネージャ」 Xウィンドウマネージャっているの？を参照してください。 「ウィジェット・ツールキット」 アプリにはボタンやスクロールバー、テキスト入力など、さまざまな部品が使われていますが、これらを一から作るのは、とても手間です。 ウィジェット・ツールキットは、それら部品がまとめられたライブラリ（プログラム）です。 GTK+(GNOME)や Qt(KDE)が有名ですが、アプリを作成するのに必ずいるという訳ではなく、プログラマーの手間を軽減するためのものに過ぎません。 「Xディスプレイマネージャ」 パソコンの電源を入れ、しばらくするとグラフィカルなログインの画面が表示されます。そのログインの画面がXディスプレイマネージャです。 Xディスプレイマネージャが無い場合、パソコンの電源を入れた後に、tty画面を起動して、"startx"を入力したいといけなくなりますが、無くても全然困らないものです。 「デスクトップ環境」 デスクトップ環境は、いろいろなGUIソフトウェアをまとめたソフトウェアスイートですが、デスクトップ環境≒（ニアイコール）Xウィンドウマネージャと考えてもあながち間違いではありません。なぜなら、例えば私の場合、デスクトップ環境にXfceを使ってるのでXウィンドウマネージャはxfwm4になります。このxfwm4を変えることはありませんが、ファイルマネージャ(Thunar)以外は、GNOMEのテキストエディタ(gedit)、GNOMEの端末を使っています。どのデスクトップ環境を選んでもXウィンドウマネージャ以外は簡単に自由に選択できます。そして、ウィジェット・ツールキットも、必要に応じてGTK+(GNOME)やQt(KDE)など自由にインストールできます。 団体と、主な提供物 X.Org Foundation ・Xウィンドウシステム(資料) ・Xサーバ(ソフトウェア) ・Xlib(ライブラリ) freedesktop.org (旧名称: X Desktop Group(XDG)) ・Extended Window Manager Hints(資料) ・X clipboard explanation(資料) ・DnD(a drag-and-drop specification)(資料) GNOME ・Mutter(Xウィンドウマネージャ) ・GTK+(ウィジェット・ツールキット) KDE ・KWin(Xウィンドウマネージャ) ・Qt(ウィジェット・ツールキット) The Linux kernel(Linuxカーネル) ・DRM(ドライバ) ・KMS(ドライバ) まとめ LinuxのGUIは解りにくいと感じます。なぜなら、複数の団体があり、似たようなソフトウェアがあり、過去の使わなくなった機能から実験的な機能まで、こんがらがってあるからです。Linuxに馴染みの薄いと混乱してしまいます。 ここで紹介した用語はLinuxのGUIの一部ですし、説明が主観的です。それでも、筆者の記憶の整理と、読者の知識の整理に役立つのではないかと考えます。
Xウィンドウシステムに関連してよく目にする用語として、Xウィンドウマネージャ、Xサーバ、デスクトップ環境、GTK+などがあります。 「これら一体何なの？」私がLinuxを触り始めたころ、チンプンカンプンでした。 今回、これらの用語を解説したいと思います。正確で漏れのない解説ではなく、初心者に分かりやすい解説をめざしています。より詳しい解説は、各用語ごとにウィキペディアへのリンクを張っていますのでそちらを参照してください。 （注意、筆者の主観が多分に混じっているため、間違っていたらごめんなさい。そして、ご指摘を歓迎します）
まず最初にGUI(グラフィカル・ユーザ・インターフェース)とCUI(キャラクタユーザインタフェース)の違いをざっくり説明します。 ・CUIは、キーボードとディスプレイしか制御できない上に、アルファベット文字と一般記号しか扱えない。 ・GUIは、好きな図形や絵や文字が表示でき、マウスポインターなど使って直感的な操作ができる。 古いパソコンはCUIしか備えていませんでした。1960代にコンピュータの使い勝手をよくするためにGUIという考え方が登場しました。 主観的には、GUIが普及し始めたのは1990年代、そして、1995年のWindows95で爆発的にGUIが普及したと感じています。
GUIを実現するための仕組みやソフトウェアの総称。特定の資料やソフトウェアを指しているものではありません。
ウィキペディアによると、 "X Window Systemとは、ビットマップディスプレイ上でウィンドウシステムを提供する表示プロトコルである。リファレンス実装として X.Org Server があり、標準ツールキットとプロトコルを提供し、Unix系オペレーティングシステム (OS) やOpenVMSなどでのグラフィカルユーザインタフェース (GUI) を構築するのに使われる。他の多くの汎用OSにも移植されている。" となっています。
Xウィンドウシステムとは、仕組みや方法をまとめた資料。と、私は解釈しました。 なので、Xウィンドウシステムというソフトウェアは存在しないのですが、それでは解りづらいということでリファレンス実装のソフトウェアが作成されました。元々はリファレンス実装なのですが、他にXウィンドシステムに準拠したソフトウェアが存在しなかったために(以前はXFree86があったが)、このリファレンス実装が事実上の標準になっていると考えると納得がいきます。(狭義では、https://www.x.org/releases/X11R7.7/doc/ の Protocol specifications: 部分。広義では、このURL全体)
LinuxのGUI ＝ Xウィンドウシステム は、あながち間違いではありませんが、Linuxをより深く知ろうとするならば、 ・Xサーバ ・Xウィンドウマネージャ ・ウィジェット。ツールキット ・アプリのGUI機能 などのソフトウェアが連携してLinuxのGUIが成り立っていることを意識し、それぞれの役割を理解するべきです。
なお、開発元は、"X Window System"の他に、別名として"X"や"X11"を使うことを求めています。
Xウィンドウシステムに準拠したソフトウェア（キーボート、マウスなどからの入力と、ディスプレイへの表示を行うソフトウェア）。 アプリ(ブラウザやオフィースソフトなど)が直接ハードウェアを制御してGUIを実現することもできるのですが、そうしてしまうと、他のアプリがキーボートやマウス、ディスプレイを使えなくなります。そうならないようにXサーバがハードウェアとアプリを仲介をします。 画像や図形をディスプレイに表示するための機能(グラフィックコンテキスト)をアプリに提供するのもXサーバの役割です。ちなみに音(audio)やプリンタはXサーバは関与しません。
※名称は、"X.Org Server"の他に、"XServer"、"X.Orgサーバー"、"Xサーバー"と表記されている場合を見かけます。また"Xサーバ"と語尾に"ー"が付かないのは"プリンタ"や"メモリ"と同じ表記ゆれです。
Xウィンドウシステムに準拠したソフトウェア。Xサーバと似た機能を提供していましたが、今ではメンテナンスが終了しています。なのでXウィンドウシステムに準拠したGUIはXサーバのみとなっています。
Waylandは、Xサーバを置き換える存在です。 XサーバはXウィンドウシステム(X11プロトコル)に準拠しています。しかし、このX11プロトコルの初版リリースは1987年とかなり古く、近年のGPUや高解像度などにそぐわなくなってきています。 Waylandはグラフィクス周りのみに特化しており、Xサーバの全ての機能を置き換えるというわけではありません。
Xウィンドウマネージャっているの？を参照してください。
アプリにはボタンやスクロールバー、テキスト入力など、さまざまな部品が使われていますが、これらを一から作るのは、とても手間です。 ウィジェット・ツールキットは、それら部品がまとめられたライブラリ（プログラム）です。 GTK+(GNOME)や Qt(KDE)が有名ですが、アプリを作成するのに必ずいるという訳ではなく、プログラマーの手間を軽減するためのものに過ぎません。
パソコンの電源を入れ、しばらくするとグラフィカルなログインの画面が表示されます。そのログインの画面がXディスプレイマネージャです。 Xディスプレイマネージャが無い場合、パソコンの電源を入れた後に、tty画面を起動して、"startx"を入力したいといけなくなりますが、無くても全然困らないものです。
デスクトップ環境は、いろいろなGUIソフトウェアをまとめたソフトウェアスイートですが、デスクトップ環境≒（ニアイコール）Xウィンドウマネージャと考えてもあながち間違いではありません。なぜなら、例えば私の場合、デスクトップ環境にXfceを使ってるのでXウィンドウマネージャはxfwm4になります。このxfwm4を変えることはありませんが、ファイルマネージャ(Thunar)以外は、GNOMEのテキストエディタ(gedit)、GNOMEの端末を使っています。どのデスクトップ環境を選んでもXウィンドウマネージャ以外は簡単に自由に選択できます。そして、ウィジェット・ツールキットも、必要に応じてGTK+(GNOME)やQt(KDE)など自由にインストールできます。
X.Org Foundation ・Xウィンドウシステム(資料) ・Xサーバ(ソフトウェア) ・Xlib(ライブラリ) freedesktop.org (旧名称: X Desktop Group(XDG)) ・Extended Window Manager Hints(資料) ・X clipboard explanation(資料) ・DnD(a drag-and-drop specification)(資料) GNOME ・Mutter(Xウィンドウマネージャ) ・GTK+(ウィジェット・ツールキット) KDE ・KWin(Xウィンドウマネージャ) ・Qt(ウィジェット・ツールキット) The Linux kernel(Linuxカーネル) ・DRM(ドライバ) ・KMS(ドライバ)
LinuxのGUIは解りにくいと感じます。なぜなら、複数の団体があり、似たようなソフトウェアがあり、過去の使わなくなった機能から実験的な機能まで、こんがらがってあるからです。Linuxに馴染みの薄いと混乱してしまいます。 ここで紹介した用語はLinuxのGUIの一部ですし、説明が主観的です。それでも、筆者の記憶の整理と、読者の知識の整理に役立つのではないかと考えます。
Qiiaに投稿してみるにあたり、自分のブログに掲載した内容をQiia向けに修正して投稿してみることに。画像挿入や見出しや引用など、修正する作業量は割と多かった。 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でlocalhost:8080にアクセス Firefoxで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 IMAGE ID f35646e83998 ⑭dockerのイメージを削除 # docker rmi f35646e83998 ⑮dockerのイメージの状態の情報表示 # docker images dockerのコンテナは削除したが、dockerのイメージは残っている。dockerのイメージの情報表示を行い、IMAGE IDを指定してdockerのイメージを削除、再度dockerのイメージの情報表示を行い、dockerのイメージが無くなったことを確認している。
Qiiaに投稿してみるにあたり、自分のブログに掲載した内容をQiia向けに修正して投稿してみることに。画像挿入や見出しや引用など、修正する作業量は割と多かった。
CentOS8にNginxを入れずにNginx起動することは可能だ。具体的にはdockerをインストールしてdockerを利用してNginxを起動する。 # nginx -V
# nginx -V
CentOS8にはNginxをインストールしていないので、コマンドが見つかりませんでしたのメッセージ。その後にnginx のインストールを促してくるがNo。この状態でdockerをインストールしてdockerを利用してNginxを起動してみる。
docs.docker.comのCentOSにDockerエンジンをインストールするを参考にしようかと思ったが、CentOS7を対象としており、CentOS8向けではなかった。そのため、CentOs8にdockerをインストールを参考にさせてもらいインストールの実施をすることにした。
手順としては ①CentOSにDockerエンジンをインストールするを参考に、一応古いバージョンのアンインストールを実施 # dnf remove docker docker-client docker-client-latest docker-common docker-latest docker-latest-logrotate docker-logrotate docker-engine
# 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)
# cat /etc/centos-release
③リポジトリの追加 確認 # dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
# dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
④リポジトリの確認 # dnf repolist
# dnf repolist
⑤DockerEngineのインストールを実施（失敗） # dnf install --nobest docker-ce
# dnf install --nobest docker-ce
CentOS8をインストール直後の状態では、古いバージョンのdockerアンインストールは対象が無かったので「①CentOSにDockerエンジンをインストールするを参考に、一応古いバージョンのアンインストールを実施」は飛ばしてもらって問題ない。
競合するパッケージがあり、DockerEngineのインストールに失敗したので、警告通り競合するパッケージを置きかえるコマンドラインを追加して再度CentOS8にdockerのインストールを実施した ⑤DockerEngineのインストールを実施（成功） # dnf install --nobest docker-ce --allowerasing
# dnf install --nobest docker-ce --allowerasing
dockerインストールが成功したので ⑥dockerのバージョンを確認 # docker --version Docker version 19.03.13, build 4484c46d9d
# docker --version
⑦dockerの自動起動と起動設定 # systemctl enable docker # systemctl start docker
# systemctl enable docker
# systemctl start docker
を実施。
⑧dockerを利用してNginxを起動 # docker run --name testnginx -d -p 8080:80 nginx
# docker run --name testnginx -d -p 8080:80 nginx
⑨dockerのコンテナの状態の情報表示 # docker ps -a
# 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でlocalhost:8080にアクセスする。8080なのはdocker runで「-p 8080:80」と指定した為だ。 CentOS8にNginxを入れずにdockerを利用してNginx起動することに成功した。
⑩dockerのコンテナ、イメージの停止 # docker stop c917cab45486
# docker stop c917cab45486
⑪dockerのコンテナ、イメージを削除 # docker rm c917cab45486
# docker rm c917cab45486
⑫dockerのコンテナの状態の情報表示 # docker ps -a
実行中のコンテナを削除しようとするとエラーとなるので、事前にdocker stopでCONTAINER ID「c917cab45486」を指定して停止している。その後、docker rmで削除してdockerのコンテナが無くなったことをdocker ps -aで確認している。
⑬dockerのイメージの状態の情報表示 # docker images IMAGE ID f35646e83998
# docker images
⑭dockerのイメージを削除 # docker rmi f35646e83998
# docker rmi f35646e83998
⑮dockerのイメージの状態の情報表示 # docker images
dockerのコンテナは削除したが、dockerのイメージは残っている。dockerのイメージの情報表示を行い、IMAGE IDを指定してdockerのイメージを削除、再度dockerのイメージの情報表示を行い、dockerのイメージが無くなったことを確認している。
開発環境 Laravel 7.20.0 PHP 7.4 MYSQL 8.0.21 Windows version 2004 全体のおおまかな流れ Ubuntu導入 WSL2に更新・導入 dockerインストール laradock導入 本記事のゴール 本記事はWindows環境上にWSL2を用いてLinux環境を構築し、Laradockを導入して画面の表示+Migrationすることを目標としています。 まずはUbuntu導入準備から Windowsを最新状態にアップデート（下記URLでダウンロード） https://support.microsoft.com/ja-jp/help/4028685/windows-10-get-the-update PCの設定から開発者モードに変更 • 「設定(スタートボタンの歯車アイコン)」-「更新とセキュリティ」-「開発者向け」を選択 • 「開発者向け機能を使う」欄の「開発者モード」を選択して有効化 追加機能でSubsystem for Linuxを有効化 • 「コントロールパネル」-「プログラム」-「Windowsの機能の有効化または無効化」を選択 • 一覧のなかから「Windows Subsystem for Linux(Beta)」にチェックを入れる ｗindows version2004の場合は表記が「Linux用Windowsサブシステム」に変更しているためそれを有効化してください。 PC再起動 Ubuntuのインストール UbuntuとはLinuxディストリビューションの1つであり、フリーソフトウェアとして提供されている Microsoft storeでubunntuをインストール。 コマンドプロンプトでbashと入力。（Ubuntuにログイン出来たら成功） 続いてUbuntuの状態を最新にします。 $ sudo apt-get update $ sudo apt-get dist-upgrade $ sudo apt-get autoremove GitとPHPを取得 普通にインストールすると古いバージョンのGitがインストールされるので、リポジトリを追加して最新のものを取得。 下記コマンドを実行。 $ sudo apt-get install build-essential $ sudo add-apt-repository ppa:git-core/ppa $ sudo apt-get update $ sudo apt-get install git $ git --version //最新になっていたらOK git version 2.28.0 PHP ※PHP--version 7.4を指定しています。 ＄sudo apt-get install php7.4 php7.4-fpm php7.4-mysql php7.4-mbstring php7.4-gd $ php -v //指定したバージョンがインストールされているかを確認 PHP 7.4.3 (cli) (built: May 26 2020 12:24:22) ( NTS ) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies with Zend OPcache v7.4.3, Copyright (c), by Zend Technologies WSL2の事前準備 WSL2とはLinuxカーネルが動作する「本物のLinux環境」 「Windows PowerShell」の中の「Windows PowerShell」を「管理者として実行」して下記コマンドを実行 PS C:\>dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart PS C:\>dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart PCを再起動 バージョンの確認 C:¥> ver Microsoft Windows [Version 10.0.19041.84] バージョンが10.0.18917以上であることを確認 デフォルトをWSL2に設定するため、下記コマンドを実行。 C:¥> wsl --set-version ubuntu 2 WSL2に切り替わっているか確認。 C:¥> wsl -l -v NAME STATE VERSION * Ubuntu Stopped 2 WSL2を導入したのでDockerを構築するうえでの事前準備は完了 Dockerのインストール DockerとはLinux コンテナの作成と使用を実現するオープンソースのコンテナ化技術 下記URLからDocker Desktop Edgeをインストール https://docs.docker.com/docker-for-windows/wsl-tech-preview/ PC再起動 再起動後、タスクバーのdockerアイコンから「setting」を選択 「Enable the experimental WSL2 based engine」にチェックを入れ「Appli&Restart」をクリック 再起動が終わってnotificationと表示されたらOK 続いて、ResourcesのWSLIntegration内の「Enable WSL Integration」をクリック 「Ubuntu」を選択して「Appli&Restart」をクリック Dockerの動作確認 C:\Users\magic>wsl -d ubuntu $ docker -v Docker version 19.03.5, build 633a0ea838 ####Hello Worldと表示されれば成功 $ docker run hello-world To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. Hello from Docker! Laradock導入 本番環境に必要なパッケージを提供してくれる。Homesteadをより細かく分割したようなもの 前提 Laradockも含めて１プロジェクト１リポジトリで管理したいので下記構成。 ──project_dir ├ app //laravel ディレクトリ │ ├ app │ │ bootstrap │ └ .env │ └ Laradock Laradockをgit clone $git clone https://github.com/Laradock/laradock.git 設定ファイル(env-exampl)をコピーして.envを生成 $ cd laradock $ cp env-example .env コピーしたenv（Laradock.env）ファイルの編集 指定したいプロジェクトを指定 APP_CODE_PATH_HOST=../ APP_CODE_PATH_HOST=../プロジェクト名/ データの保存ディレクトリを指定 DATA_PATH_HOST=~/.laradock/data + DATA_PATH_HOST=.laradock/data プロジェクト名の設定 laradockを使ったプロジェクトを複数作る場合、プロジェクト名が同じ場合、過去に作った同じ名前のコンテナイメージが上書きされてしまいまうため、被らない名前を設定 COMPOSE_PROJECT_NAME=laradock + COMPOSE_PROJECT_NAME= MYSQLの設定 MySQLは8系になってパスワードの生成方法が変わったらしくLaravelから操作できないため下記記述を追記。 /lardock/mysqmy.cnfに下記を追加 // [mysqld]のエリアに追記する（デフォルトの場合一番下） default_authentication_plugin=mysql_native_password Laravel.envの設定 DBの設定を合わせて変更します ※DB_HOSTはdocker-compose.ymlに書かれているコンテナ内名を指定します。 DB_CONNECTION=mysql DB_HOST=mysql(既存だと127.001になっていると思うのでmysqlに修正) DB_PORT=3306 DB_DATABASE=default DB_USERNAME=default DB_PASSWORD=secret Laradockの起動 下記コマンドでlaradockを起動します。 引数には起動したいミドルウェアを指定 なお、projectが存在しない場合はroot権限で作成されてしまうため、必ず作成した状態で起動すること $ docker-compose up -d nginx mysql workspace 起動確認 $ docker-compose ps Dockerコンテナ内からLaravelをインストール dockerコンテナ内からlaravelをインストールする方法と、設定。 下記コマンドでWorkspaceコンテナに入る。 ※userオプションでユーザを指定してください。 $ docker-compose exec --user=laradock workspace /bin/bash コンテナ内で下記を実行してLaravelをインストール。 /var/www$ composer create-project --prefer-dist laravel/laravel . インストール完了したところで動作確認。 （※3306portを他に使用している場合はportが競合するためタスクマネージャーなどでportを終了させてください） Windows側のブラウザで、http://localhostにアクセスします。 画面が表示されればインストール完了 マイグレーションの確認 MySQLの設定が完了したか、マイグレーションで確認してみましょう。 下記のようにDBにテーブルが作成されれば成功 /var/www$ php artisan migrate Migration table created successfully. Migrating: 2014_10_１９000000_create_users_table Migrated: 2014_10１９000000_create_users_table (0.36 seconds) Migrating: 2014_10１９100000_create_password_resets_table Migrated: 2014_10１９100000_create_password_resets_table (0.35 seconds) Migrating: 2019１０19_000000_create_failed_jobs_table Migrated: 2019１０_19_000000_create_failed_jobs_table (0.1 seconds) 終わりに 今回はWindows環境にLaradockを導入するまでの流れを記事として投稿しました それと来月でプログラミングを始めてから一年経つこともあり、当初よりも知見が深まったこともあるので、これから少しずつ技術記事を上げていこうと思います。 どうかよろしくお願いいたしますm(._.)m
Laravel 7.20.0 PHP 7.4 MYSQL 8.0.21 Windows version 2004
本記事はWindows環境上にWSL2を用いてLinux環境を構築し、Laradockを導入して画面の表示+Migrationすることを目標としています。
https://support.microsoft.com/ja-jp/help/4028685/windows-10-get-the-update
• 「設定(スタートボタンの歯車アイコン)」-「更新とセキュリティ」-「開発者向け」を選択 • 「開発者向け機能を使う」欄の「開発者モード」を選択して有効化
• 「コントロールパネル」-「プログラム」-「Windowsの機能の有効化または無効化」を選択 • 一覧のなかから「Windows Subsystem for Linux(Beta)」にチェックを入れる
ｗindows version2004の場合は表記が「Linux用Windowsサブシステム」に変更しているためそれを有効化してください。
PC再起動
UbuntuとはLinuxディストリビューションの1つであり、フリーソフトウェアとして提供されている
Microsoft storeでubunntuをインストール。
コマンドプロンプトでbashと入力。（Ubuntuにログイン出来たら成功）
続いてUbuntuの状態を最新にします。
$ sudo apt-get update $ sudo apt-get dist-upgrade $ sudo apt-get autoremove
普通にインストールすると古いバージョンのGitがインストールされるので、リポジトリを追加して最新のものを取得。
下記コマンドを実行。
$ sudo apt-get install build-essential $ sudo add-apt-repository ppa:git-core/ppa $ sudo apt-get update $ sudo apt-get install git $ git --version //最新になっていたらOK git version 2.28.0
※PHP--version 7.4を指定しています。
＄sudo apt-get install php7.4 php7.4-fpm php7.4-mysql php7.4-mbstring php7.4-gd $ php -v //指定したバージョンがインストールされているかを確認 PHP 7.4.3 (cli) (built: May 26 2020 12:24:22) ( NTS ) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies with Zend OPcache v7.4.3, Copyright (c), by Zend Technologies
WSL2とはLinuxカーネルが動作する「本物のLinux環境」
PS C:\>dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
PS C:\>dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
C:¥> ver Microsoft Windows [Version 10.0.19041.84]
C:¥> wsl --set-version ubuntu 2
WSL2に切り替わっているか確認。
C:¥> wsl -l -v NAME STATE VERSION * Ubuntu Stopped 2
DockerとはLinux コンテナの作成と使用を実現するオープンソースのコンテナ化技術
https://docs.docker.com/docker-for-windows/wsl-tech-preview/
再起動後、タスクバーのdockerアイコンから「setting」を選択 「Enable the experimental WSL2 based engine」にチェックを入れ「Appli&Restart」をクリック
再起動が終わってnotificationと表示されたらOK
続いて、ResourcesのWSLIntegration内の「Enable WSL Integration」をクリック
「Ubuntu」を選択して「Appli&Restart」をクリック
C:\Users\magic>wsl -d ubuntu $ docker -v Docker version 19.03.5, build 633a0ea838
$ docker run hello-world To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. Hello from Docker!
本番環境に必要なパッケージを提供してくれる。Homesteadをより細かく分割したようなもの
Laradockも含めて１プロジェクト１リポジトリで管理したいので下記構成。
──project_dir ├ app //laravel ディレクトリ │ ├ app │ │ bootstrap │ └ .env │ └ Laradock
$git clone https://github.com/Laradock/laradock.git
$ cd laradock $ cp env-example .env
APP_CODE_PATH_HOST=../ APP_CODE_PATH_HOST=../プロジェクト名/
DATA_PATH_HOST=~/.laradock/data + DATA_PATH_HOST=.laradock/data
laradockを使ったプロジェクトを複数作る場合、プロジェクト名が同じ場合、過去に作った同じ名前のコンテナイメージが上書きされてしまいまうため、被らない名前を設定 COMPOSE_PROJECT_NAME=laradock + COMPOSE_PROJECT_NAME=
laradockを使ったプロジェクトを複数作る場合、プロジェクト名が同じ場合、過去に作った同じ名前のコンテナイメージが上書きされてしまいまうため、被らない名前を設定
COMPOSE_PROJECT_NAME=laradock + COMPOSE_PROJECT_NAME=
MySQLは8系になってパスワードの生成方法が変わったらしくLaravelから操作できないため下記記述を追記。
/lardock/mysqmy.cnfに下記を追加
// [mysqld]のエリアに追記する（デフォルトの場合一番下） default_authentication_plugin=mysql_native_password
DBの設定を合わせて変更します ※DB_HOSTはdocker-compose.ymlに書かれているコンテナ内名を指定します。
DB_CONNECTION=mysql DB_HOST=mysql(既存だと127.001になっていると思うのでmysqlに修正) DB_PORT=3306 DB_DATABASE=default DB_USERNAME=default DB_PASSWORD=secret
下記コマンドでlaradockを起動します。 引数には起動したいミドルウェアを指定
なお、projectが存在しない場合はroot権限で作成されてしまうため、必ず作成した状態で起動すること $ docker-compose up -d nginx mysql workspace
なお、projectが存在しない場合はroot権限で作成されてしまうため、必ず作成した状態で起動すること
$ docker-compose up -d nginx mysql workspace
起動確認
$ docker-compose ps
dockerコンテナ内からlaravelをインストールする方法と、設定。
下記コマンドでWorkspaceコンテナに入る。
※userオプションでユーザを指定してください。 $ docker-compose exec --user=laradock workspace /bin/bash
※userオプションでユーザを指定してください。
$ docker-compose exec --user=laradock workspace /bin/bash
コンテナ内で下記を実行してLaravelをインストール。
/var/www$ composer create-project --prefer-dist laravel/laravel .
インストール完了したところで動作確認。 （※3306portを他に使用している場合はportが競合するためタスクマネージャーなどでportを終了させてください）
Windows側のブラウザで、http://localhostにアクセスします。
マイグレーションの確認 MySQLの設定が完了したか、マイグレーションで確認してみましょう。
下記のようにDBにテーブルが作成されれば成功
/var/www$ php artisan migrate Migration table created successfully. Migrating: 2014_10_１９000000_create_users_table Migrated: 2014_10１９000000_create_users_table (0.36 seconds) Migrating: 2014_10１９100000_create_password_resets_table Migrated: 2014_10１９100000_create_password_resets_table (0.35 seconds) Migrating: 2019１０19_000000_create_failed_jobs_table Migrated: 2019１０_19_000000_create_failed_jobs_table (0.1 seconds)
今回はWindows環境にLaradockを導入するまでの流れを記事として投稿しました
それと来月でプログラミングを始めてから一年経つこともあり、当初よりも知見が深まったこともあるので、これから少しずつ技術記事を上げていこうと思います。 どうかよろしくお願いいたしますm(._.)m
