20210113のLinuxに関する記事は7件です。

投稿日：2021-01-13T23:04:22+09:00

glibc, musl libc, go の resolver の違い

先日、resolv.conf で timeout を調整したいなと思うことがありました、しかし、Docker だの Kubernetes だのといった時代です。Linux しか使っていなかったとしても resolver が glibc のそれだとは限らないわけですね。そこで glibc, musl libc (alpine のやつです), go の resolver の違いを調べてみました。

環境

それぞれ docker container を使い、問い合わせの状況は tcpdump で確認しました。
macOS Catalina (10.15.7)
docker desktop 3.0.3 (51017)
container image は
alpine:3.12.3 / musl-1.1.24-r10
debian:buster-20201209 (10.7) / glibc 2.28-10
Go は mac 上で 1.15.6 を使い、クロスコンパイルして上記の alpine 上で実行しました。
クロスコンパイルなのでデフォルトで CGO_ENABLED=0 のはずですが、明示してビルドしました。

resolv.conf の options などの対応状況
resolv.confの例
nameserver 8.8.8.8
nameserver 8.8.4.4
search default.svc.cluster.local svc.cluster.local cluster.local asia-northeast1-b.c.project-id.internal c.project-id.internal google.internal
options ndots:5 timeout:5 attempts:2
resolv.conf の options にはいろいろありますが、今回の 3 つの resolver 全てで対応されているのは

ndots

timeout

attempts

の3つでした。

nameserver は勿論ですが search にも対応しています。
昔の musl libc は search (domain 補完) には対応していませんでしたが 1.1.13 から対応していました。
nameserver は複数回指定可能ですが、使われるのは3つまでです。4つ以上指定しても3つまでしか使われません。

それでは機能の違いを見ていきましょう

ndots

まずは ndots です、Kubernetes を使うようになってはじめて知りました。

指定するのは問い合わせるドメインに含まれる dot (.) の数です、Kubernetes のデフォルト設定では 5 (ndots:5) となっています。

例えば ping www.google.com とした場合、dot の数は 2 です。

dot の数が ndots 以上の場合

dot の数が ndots で指定した以上であればそれは FQDN であろうと判断し、search で指定したドメインを補完せずに DNS サーバーに問い合わせます。ここで、NXDOMAIN (そんなドメイン存在しないよ) が返ってきたら glibc と go は search で指定したドメインを補完して問い合わせます。しかし、musl libc は補完した問い合わせを行わないでそんなドメインは存在しないよということで終了してしまいます。

その昔、musl はそもそもドメイン補完に対応していなかったので当時から使っている人は常に FQDN で指定しているでしょうから問題ないでしょうが、知らないで ndots を小さくすると解決できるはずのドメインが解決できないかもしれません。

dot の数が ndots 未満の場合

dot の数が ndots 未満であった場合はまず search で指定した複数のドメインを順番に補完して問い合わせます、見つかるまで繰り返すため（これの上限を確認するの忘れた）、順序は重要ですかね。ただ、順序以上に ndots で指定する数が重要です、5 というのは結構多いです。Kubernetes でデフォルト設定だと service.namespace.svc.cluster.local という FQDN を指定したとしても 4 なわけです。search に並んでいる全てのドメインの補完を試した後に service.namespace.svc.cluster.local をそのまま問い合わせてやっと欲しい結果が得られるわけです、DNS サーバー側にネガティブキャッシュがあるとはいえ、DNS サーバーとの通信はその回数行われるわけですから、かなりの無駄です。GKE のデフォルト設定では6つもドメインが列挙されています。EKS は4つ。ndots を小さくして名前解決ができないドメインが発生してしまうよりも、無駄な問い合わせが増えたとしても名前解決できる値がデフォルトなっているわけですね。ndots はチューニングの余地がありそうです。

ちなみに、末尾に . をつけた場合はそれは FQDN だぞということを意味するので ping www.google.com. などとした場合はどの resolver でもドメインの補完は行いません。

nameserver

複数サーバーを指定した場合の扱いが glibc と musl で大きく異なるため、まず説明しておきます。
glibc と Go は一つ目のサーバーに問い合わせて、timeout 秒待っても応答がない場合に、次のサーバーに問い合わせます。
musl libc は複数の nameserver に同時にリクエストを送って最初に返ってきた応答を使います。3つのネームサーバーが指定されていたら3倍の問い合わせが発生してしまうわけですね。

timeout と attempts

timeout と attempts は関連しているため一緒に扱います。また、nameserver の数にもよるためそれごとにまとめます。

nameserver が1つの場合

glibc と Go は問い合わせを投げては timeout 秒待ち、応答がなければ再度問い合わせて、合計 attempts 回問い合わせます。

musl libc は timeout 秒を attempts で割った秒数をそれぞれの問い合わせで待ちます。つまり、リトライを含めた合計で最大 timeout 秒待つということです。 timeout:5 attempts:2 というデフォルト設定では 2.5 秒ずつ待ちます。

nameserver が2つの場合

glibc と Go は1つ目の nameserver に問い合わせて timeout 秒待ち、次は2つ目の nameserver に問い合わせます。これが attempts の1回分です。timeout:5 attempts:2 というデフォルト設定ではそれぞれの nameserver に対して2回ずつ、合計4回問い合わせます。その都度5秒待ちます。

musl libc は nameserver の項で書いた通り、複数の nameserver に対して同時に問い合わせるため、nameserver が1つの場合と同じです。

nameserver が3つの場合

nameserver が3つになると glibc の timeout の振る舞いが少し変わります。1つ目の nameserver に対しては timeout で指定した秒数待ちますが、2つ目は timeout で指定したのよりも短くなり、3つ目は timeout で指定したものより長くなります。
timeout:5 の場合は5秒、3秒、6秒となります。このセットを attempts 回繰り返します。

Go は常に timeout 秒待ちます。

musl libc はこれまでと同じです。

timeout 時のドメイン補完

何度問い合わせても timeout するような場合はもういろいろダメなのであまり重要ではないですが、動作に違いがあったので書いておきます。

timeout が続く状態で、2つ目以降の search ドメインを補完するのかどうか、glibc は2つ目以降のドメイン補完は行いませんが、補完なしの問い合わせを行います。Go は律儀に全てのドメイン補完を試しますし、補完なしでの問い合わせもします。musl libc は1つ目の補完の問い合わせは行いますが、それで終わりです。補完なしの問い合わせもありません。

Go の動作確認で使ったコード
package main

import (
    "context"
    "net"
    "os"
    "log"
)

func main() {
    ctx := context.Background()
    resolver := &net.Resolver{}
    for _, v := range os.Args[1:] {
        log.Printf("Resolving %s\n", v)
        names, err := resolver.LookupHost(ctx, v)
        if err != nil {
            log.Fatal(err)
        }
        for _, name := range names {
            log.Printf("%s\n", name)
        }
    }
}
ndots:5 の凶悪さを可視化する

文章でつらつら書いても分かりづらいので、 GKE 環境で storage.googleapis.com にアクセスしようとした場合にどんな問い合わせが発生するかを見てみましょう。default namespace に立てた Pod で ping storage.googleapis.com を実行した際の tcpdump の出力を加工しました。(横幅を抑えるために)

Cloud Storage の API にアクセスしようとする度にこの数の問い合わせが発生すると思うとゾッとしますね。マイクロサービスで Keep-Alive などをしていない場合は大量の内部通信でもこれが発生しているかもしれません。JVM などのように DNS のキャッシュをしてくれれば良いですけどね。

ndots:2 として常に FQDN で指定するということが徹底できると良いのかな。
14:53:34.706909 ▶︎ A? storage.googleapis.com.default.svc.cluster.local. (66)
14:53:34.707130 ▶︎ AAAA? storage.googleapis.com.default.svc.cluster.local. (66)
14:53:34.708881 ◁ NXDomain 0/1/0 (159)
14:53:34.708940 ◁ NXDomain 0/1/0 (159)
14:53:34.709051 ▶︎ A? storage.googleapis.com.svc.cluster.local. (58)
14:53:34.709133 ▶︎ AAAA? storage.googleapis.com.svc.cluster.local. (58)
14:53:34.709615 ◁ NXDomain 0/1/0 (151)
14:53:34.709689 ◁ NXDomain 0/1/0 (151)
14:53:34.709771 ▶︎ A? storage.googleapis.com.cluster.local. (54)
14:53:34.709816 ▶︎ AAAA? storage.googleapis.com.cluster.local. (54)
14:53:34.712211 ◁ NXDomain 0/1/0 (147)
14:53:34.712280 ◁ NXDomain 0/1/0 (147)
14:53:34.712387 ▶︎ A? storage.googleapis.com.asia-northeast1-b.c.my-project-id.internal. (83)
14:53:34.712479 ▶︎ AAAA? storage.googleapis.com.asia-northeast1-b.c.my-project-id.internal. (83)
14:53:34.716561 ◁ NXDomain 0/1/0 (189)
14:53:34.716623 ◁ NXDomain 0/1/0 (189)
14:53:34.716718 ▶︎ A? storage.googleapis.com.c.my-project-id.internal. (65)
14:53:34.716760 ▶︎ AAAA? storage.googleapis.com.c.my-project-id.internal. (65)
14:53:34.719891 ◁ NXDomain 0/1/0 (162)
14:53:34.720191 ◁ NXDomain 0/1/0 (162)
14:53:34.720304 ▶︎ A? storage.googleapis.com.google.internal. (56)
14:53:34.720390 ▶︎ AAAA? storage.googleapis.com.google.internal. (56)
14:53:34.724145 ◁ NXDomain 0/1/0 (145)
14:53:34.724352 ◁ NXDomain 0/1/0 (145)
14:53:34.724458 ▶︎ A? storage.googleapis.com. (40)
14:53:34.724500 ▶︎ AAAA? storage.googleapis.com. (40)
14:53:34.726930 ◁ 4/0/0 AAAA 2404:6800:4004:813::2010, AAAA 2404:6800:4004:81c::2010, AAAA 2404:6800:4004:81d::2010, AAAA 2404:6800:4004:81e::2010 (152)
14:53:34.726957 ◁ 16/0/0 A 172.217.161.80, A 172.217.175.16, A 172.217.175.48, A 172.217.175.80, A 172.217.175.112, A 216.58.197.144, A 172.217.25.208, A 172.217.25.240, A 172.217.26.48, A 172.217.31.176, A 172.217.161.48, A 172.217.174.112, A 172.217.175.240, A 216.58.220.112, A 216.58.197.208, A 216.58.197.240 (296)

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-13T22:00:46+09:00

Laravelで手軽にログイン認証機能を実装する

【前提条件】
Lamp環境が正常にインストール出来ている。
Node.jsのインストールが出来ている。
データ・ベースの設定が出来ている。
artisanコマンドがある程度扱える。

Node.jsがインストール出来ていない方は@seiba様の記事を参照して下さい
【引用リンク】
https://qiita.com/seibe/items/36cef7df85fe2cefa3ea

1、バージョンを確認する

まずはLaravelのバージョンを確認しましょう、以下のコマンドを入力して下さい。
php artisan --version
Laravelのバージョンが6系か7系かを確認します。

2、Laravel/uiをインストールする。

６系の場合は以下のコマンドでインストール
composer require laravel/ui:^1.0 --dev
7系の場合は以下のコマンドでインストール
composer require laravel/ui:^2.4
3、認証機能を実装する

６系、７系共通で以下のコマンドを入力してログイン機能を実装する
php artisan ui vue --auth
この時点ではログイン機能は完成していません、この時点でREGISTER場面を
見てみると………フロントエンド部分が実装されていません。

4、フロントエンド部分を実装する〜完成

npmをインストールする
npm install
npmをビルドする
npm run dev
最期に忘れずにmigrationコマンドででログイン情報を格納するテーブルを作成する。
php artisan migration
完成です
Laravelを立ち上げてみて右端のRegisterをクリックしてみる

すると先程は実装されていなかったフロントエンド部分の実装がなされている。

実際に登録してみる

実際にログインに成功するとログイン後のページに遷移できる。

番外編:どのようにデータが格納されているか

実際にパスワードが格納されているテーブルを見てみるとパスワードが暗号化されて格納されており、手軽に実装出来てかなり高度な認証機能である事がわかる。
|  1 | ララベルユーザー       | laravel@gmail.com | NULL |
 $2y$10$KPPRJJH0fOYl1JocEdQscu3NNl5BrJU.MpEu4AY1I2ye6F5z18Zsq | NULL           | 2021-01-13 12:40:02 | 2021-01-13 12:40:02 |
+----+--------------------+-------------------+-------------------+--------------------------------------------------------------+----------------+---------------------+---------------------+
参考サイト
【公式版】Laravel公式チュートリアル日本語訳
https://readouble.com/laravel/7.x/ja/authentication.html

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-13T16:15:11+09:00

RaspberryPi 4 Model B で USBポートの電源をON/OFFする　リトライ

RaspberryPi 4 Model B で USBポートの電源をON/OFFする - Qiita
のリトライ版

目標

ラズパイに接続したUSBカメラ映像で異常検知を行い、パトランプで警告を行う

構成

BUFFALO 電源連動節電機能付き 4ポートセルフパワーハブブラック BSH4AE12BK

SANWA SUPPLY TAP-RE10SPUN 高性能雷連動タップ 7個口

LED回転灯ニコFAX φ45 VL04S型 VL04P-100FAN

USBハブは、Per-port power switching対応のものを使いたかったのだが、BSH4AE12BKが使えるという情報があり、お安かったのでそちらを使った。
パトライトについては、FAX検知用のがお安かったので、それを使いった。
用紙検知部に白紙を巻きつけるだけで常時点灯する。

Per-port power switchingとは

USBハブのポート毎に電源供給をON/OFFできる仕組み。
対応のハブはLinuxであれば、
sudo lsusb -v | less
で、該当のハブのところに
wHubCharacteristic 0x0009
  Per-port power switching
  Per-port overcurrent protection
と表示されれば使える可能性が高い。
（めっちゃ大量に出てくるのでless推奨）
可能性が高い、というのは、ラズパイ4では上記表示があるのにも関わらず、個別制御が出来ないから。
めんどくさっ！

ラズパイ4のUSB構成

物理的配置は、こう
 LAN
+---+  Port1 Port2（USB3.0)
|   |
+---+  Port3 Port4（USB2.0)
論理的配置は、多分こんな感じ
Hub1（Root) - Hub 1.1(USB2.0) - Hub 2(USB3.0) 
                ├ Port1          ├ Port1
                ├ Port2          ├ Port2
                ├ Port3          ├ Port3
                └ Port4          └ Port4
全ポートをON/OFFしていいのであれば、以下でOKだが、個別に制御したいんだよおおおおお。
sudo uhubctl -l 1-1 -a off
事前準備

前の記事では、hub-ctrlを使ったが、その後調べたところ、より使い勝手の良いものが公開されていたので、こちらを使った。
GitHub - mvp/uhubctl: uhubctl - USB hub per-port power control

ファームウェアアップデート

ファームウェアが古いとそもそも動かないらしいのでアップデート。
sudo apt update
sudo apt full-upgrade
sudo reboot
コマンドインストール
git clone https://github.com/mvp/uhubctl
cd uhubctl
make
sudo make install
HUB確認

コマンドを引数なしで呼ぶと、対応しているハブを列挙してくれる。
が、必ずしも確実に対応しているわけではないので、実際に給電状況を見て確認する必要がある。
GitHubのページでも、実際に適当なスマホとかライトとかを繋いで通電確認せよ、とある。
マジめんどくせぇ。。。
sudo uhubctl
Current status for hub 2 [1d6b:0003 Linux 5.4.83-v7l+ xhci-hcd xHCI Host Controller 0000:01:00.0, USB 3.00, 4 ports, ppps]
  Port 1: 02a0 power 5gbps Rx.Detect
  Port 2: 02a0 power 5gbps Rx.Detect
  Port 3: 02a0 power 5gbps Rx.Detect
  Port 4: 02a0 power 5gbps Rx.Detect
Current status for hub 1-1 [2109:3431 USB2.0 Hub, USB 2.10, 4 ports, ppps]
  Port 1: 0507 power highspeed suspend enable connect [05e3:0608 USB2.0 Hub, USB 2.00, 4 ports, ganged]
  Port 2: 0107 power suspend enable connect [1e4e:0100 GroupGets PureThermal (fw:v1.3.0) 800c0031-5109-3538-3731-313200000000]
  Port 3: 0100 power
  Port 4: 0100 power
Current status for hub 1 [1d6b:0002 Linux 5.4.83-v7l+ xhci-hcd xHCI Host Controller 0000:01:00.0, USB 2.00, 1 ports, ppps]
  Port 1: 0503 power highspeed enable connect [2109:3431 USB2.0 Hub, USB 2.10, 4 ports, ppps]
上記で1-1.1に繋がれているHUBをON/OFFする
HUB自体は、Per-port power switching対応していないので、「-f」オプションを付ける
sudo uhubctl -l 1-1.1 -f -a off
「.1」の部分を.2～.4に変更しても動くが、
USB2.0のポート（3,4）を使う場合でも
sudo uhubctl -l 1-1.4 -f -a off
と指定する必要があるので注意。

推測など

BUFFALO 電源連動節電機能付き 4ポートセルフパワーハブブラック BSH4AE12BK

↑は外部給電対応でありながら、大本のUSBの電源連動する、ということで、内部的に何らかのエミュレーション（または誤動作）をしているものと思われる。

また、給電制御ということで、個別ポートの過電圧検知が付いていたり、個別に給電をON/OFFできるハブは、Per-port power switching対応している……かもしれない。

GitHubの情報によると、こちらのメーカーのHUBが対応しているらしい。
（GitHubに報告があるのは16ポート）

ROSONWAY USB ハブ 3.0 16ポートアルミ製 USB Hub 100W セルフパワー USBハブ 5Gbps高速転送 12V/8.3A ACアダプタ付き独立スイッチ


USBハブ 3.0 ROSONWAY アルミ製 7ポート USB3.0 Hub 24W電源付きバスパワーとセルフパワー両用独立スイッチ 5Gbps高速転送、12V/2A ACアダプター


今回はBSH4AE12BKで目的達成してしまったので、今後機会があれば上記HUBも試してみたい。

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-13T13:50:48+09:00

iostat

I/Oの状況を確認できる。
# iostat
Linux 3.10.0-862.3.3.el7.x86_64 (testserver)      2021年01月13日  _x86_64_        (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.04    0.00    0.06    0.00    0.08   99.82

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
xvda              0.37         0.01         2.19     265225   55131237
dm-0              0.00         0.00         0.01       9237     209248
dm-1              0.00         0.00         0.00       2252          0
dm-2              0.16         0.01         1.10     132542   27609766
dm-3              0.00         0.00         0.00       5201       2068
dm-4              0.18         0.00         1.08      85340   27148675
dm-5              0.00         0.00         0.01       3450     159390
細かく確認するには -x をつけると良いらしい。
# iostat -x
Linux 3.10.0-862.3.3.el7.x86_64 (testserver)      2021年01月13日  _x86_64_        (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.04    0.00    0.06    0.00    0.08   99.82

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvda              0.00     0.03    0.00    0.37     0.01     2.19    11.93     0.01   14.71    8.00   14.72   4.91   0.18
dm-0              0.00     0.00    0.00    0.00     0.00     0.01     9.94     0.00   12.08    7.10   12.15   9.57   0.00
dm-1              0.00     0.00    0.00    0.00     0.00     0.00    36.32     0.00    0.44    0.44    0.00   0.31   0.00
dm-2              0.00     0.00    0.00    0.16     0.01     1.10    13.82     0.00   19.91    6.51   19.93   5.49   0.09
dm-3              0.00     0.00    0.00    0.00     0.00     0.00    52.30     0.00   19.06   10.32   56.13   4.08   0.00
dm-4              0.00     0.00    0.00    0.18     0.00     1.08    11.82     0.00   16.28   11.61   16.28   4.96   0.09
dm-5              0.00     0.00    0.00    0.00     0.00     0.01     7.02     0.00    9.83   21.69    9.78   9.45   0.00
過去にディスクのI/O性能が原因で問題が発生した時、
%iowait の値が尋常ではなかった気がする。

参考

IOSTATの見方

＜抜粋＞
%util はディスクのビジー率を表していて100%が上限。
ディスクの性能がボトルネックになっているか確認したいときに使える。

ディスクがボトルネックになっているような場合は下記のような状態になる時です。
下記になっていないかをチェックするにはiostatコマンドを使用します。
・CPU 使用率の %iowait が %user よりも高くなる。
・avgqu-sz（平均I/Oキュー数）が高い。
・%utilが 100%に近づいている。
　この値はI/Oオペレーション数と平均レスポンスタイムをかけて、秒数で割ったもの。

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-13T11:22:14+09:00

Manjaro Linuxでログインパスワードを忘れたときの対応

概要

ログインパスワードを忘れたので、ログインできなくなった

対応手順

Grubメニューでkernelの末尾に init=/bin/bash を付与してF10を押下し、bashで起動する

mount -n -o remount,rw / でルートファイルシステムをread/writeでリマウント

echo userid:password | chpasswd でパスワードを変更する

ref

パスワードリカバリ - ArchWiki
https://wiki.archlinux.jp/index.php/%E3%83%91%E3%82%B9%E3%83%AF%E3%83%BC%E3%83%89%E3%83%AA%E3%82%AB%E3%83%90%E3%83%AA

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-13T10:17:05+09:00

無限再起動ループの闇に堕ちたCentOS8君をシングルユーザーモードで復旧

何をやっちゃったのか

毎日夜中にCentOS再起動させよう！

定期実行は『自作systemdを作る』でやろうじゃん！

再起動のシェルスクリプトファイル作成ヨシ！

シェルスクリプトファイルに実行権限与えるヨシ！

再起動用systemd（サービス）作成と有効化ヨシ！

上記をキックするTimer作成と有効化と実行ヨシ！

よくねーよ！！

↓これがダメだった。
再起動用systemd（サービス）作成と有効化ヨシ！

下記のようなことに…

再起動
↓
再起動用systemd（サービス）が実行されちゃう
↓
再起動
↓
再起動用systemd（サービス）が実行されちゃう
↓
……再起動の無限ループとなってしまった…(´・ω・`)

起動と同時に有効化されたサービスが走り始める が頭から抜けてましたです。

じゃあどうするのか

Linuxには シングルユーザーモード というものがあります。
最小限の構成で起動してくれるので、今回のような(ﾉ∀`)ｱﾁｬｰな時のリカバリーができます。

BIOS や Windowsのセーフモード に似たような機能って感じです。

ただし、シングルユーザーモードはネットワーク越しにはできないです。
マシンの前まで自分の足でテクテク歩いていって直接操作しないとです…。

シングルユーザーモード起動方法

まず下記のような画面になったら e を押す。

すると、こんな画面になる。

rhgb quiet の後に rd.break を入力。

そしたら、 Ctl + x でシングルユーザーモード起動できる！

ファイルを操作できるようにsysrootを再マウント

今回の目的は 間違ったシェルスクリプトファイルの修正 なので、ファイルを操作できる状態にまで持っていく必要あり。
そこでsysrootを再マウントします。

下記コマンド。
mount -o remount,rw /sysroot
chroot /sysroot
下記は再マウントして ls -l までやってみた状態。

ここまでくれば CentOS8を起動して端末を開いた のとほぼ同じ状態なので、viとかでファイルを修正できますです。

ファイルの修正が済んだのち、2回 exit したところCentOS8君が無事起動してくれました。
（再マウントしたsysrootからのexitと、シングルユーザーモードからのexitの2回）

蛇足

今回はおうちの物理サーバーだったから何とかできたけど、AWSで同じようなこと起きたらどう対処するんだろうか？

クラウドに移行する時はシングルユーザーモード的なリカバリ方法できるのかどうか確認しておこうっと…。

参考サイトさん

https://rin-ka.net/centos-7-8-single-mode-how-to/

バージョン

CentOS Linux release 8.3.2011

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-13T00:04:32+09:00

Dockerが注目される理由。そもそもDockerとは？その使い方

はじめに

　本記事は、Dockerの初学者を対象に基礎的な内容を学ぶための記事。

※追伸:こちらの記事よりも更に良い記事を見つけてしまったので、もっと詳しく知りたい方は以下をご参照ください。
・Dockerでプログラマが最低限知るべきことが、最速でわかるチュートリアル

Dockerとは

Dockerは仮想化の一つで、コンテナ型仮想化と呼ばれている。
コンテナ型仮想化はOSの上に「コンテナ」と呼ばれる仮想的な空間を作ることでOSの上に仮想的なOSを展開して、更にプロセスの実行空間を区分け(隔離)できる。

仮想化サーバーとの違い・長所

起動速度がはやい

移動が可能

稼働が軽い

リソースが有効活用可能

Dockerが注目されている理由

　一番の理由は、移動ができてリソースを有効活用できるということである。未使用のコンピュータ資源をアクティブに入れ替えながら使うことでサーバの効率化ができることから、クラウドサービスといった変動費の費用が発生するものと相性が良い。Google社では全部のソフトウェアをコンテナに乗せており、アクティブに入れ替えながら使うことでサーバの効率化をしている。

　他には従来、何かサービスをつくる場合、エンジニアは環境の制約を大きく受けていた。自分が書いたコードが本当にサーバー上で動くのか心配しながら開発を行わなければらなかった。しかし、Dockerを使うことで、自身のPCなどのdockerでコンテナを実行してながら開発をすることで、コードを仕上げ、最終的にコンテナを移動させるだけで、アプリケーションを動く状態にできるのだ。
　このことから、Dockerはインフラエンジニアのスキルに止まらず、
　→プログラマーの必須科目と言われているのである。

Dockerを使う流れ

１Dockerインストール
・OS上にDockerをインストールします。macやWindows、Linuxにインストールできる。
２Dockerfileの作成
・Dockerfileは、全く新しいDocker Imageを作成するための手順を決めるテキストファイル。したがって、インターネットから取ってくる場合など、全く新しいDocker Imageの作成をしない場合は不要。
３Docker Imageの作成
・コンテナイメージを任意の場所から持ってきて作成します。Dockerインストール後初期段階では、当然コンテナイメージは存在しないので、インターネット上からコマンド入力で持ってきます。
・インターネット上の一般的なイメージ格納場所として、「Docker Hub」というところがあります。他には、AWSのECR、さまざまな企業に独自のリポジトリサーバーに構築されて格納・管理されています。
４コンテナ起動

実際のコマンド入力

・インターネットからイメージを取得する
$ docker pull [イメージの名前]
Docker Hubでアカウントをつくり、サービス名を検索することで、コピ＆ペーストできるコマンドを見つけることもできます。Copy and paste to pull this imageのところ。

例）Apacheのイメージ取得
$ docker pull httpd
・イメージが取れたのか確認
$ docker images
・docker起動
→オプションについて
①　-d バックグラウンドでdockerを実行する
②　-p ポートの指定。[8088:80]は[ホストのポート:コンテナのポート]の関係。コンテナのポート80番をホスト側の8088で待ち受けるという意味になる。
※docker runコマンドはone liner（一行だけ）で実行でき、イメージを取得するコマンドを省略して実行できる。その場合は、自動で指定のイメージをローカルから参照する。イメージが無かったらDocker Hubから取ってきてくれる。
$ docker run -d -p 8088:80 httpd
・コンテナの状況を見る
→コンテナIDやSTUTASの項目を見ることができる。
docker ps -a
・コンテナ停止
$ docker stop [コンテナID]
・コンテナ自体の削除
$ docker rm [コンテナID]
・イメージの削除
$ docker rmi [コンテナID]
おわりに

　今回の内容ではDockerの基礎的な知識をまとめた。
　応用としては、Dockerfileの作成やdocker-composerを使い複数のコンテナを管理することなど、オーケストレーションツールを使って、複数のDockerのリソース管理をするといった内容がある。

　 Tweet
Qiitaで続きを読む

20210113のLinuxに関する記事は7件です。

glibc, musl libc, go の resolver の違い

環境

resolv.conf の options などの対応状況

ndots

dot の数が ndots 以上の場合

dot の数が ndots 未満の場合

nameserver

timeout と attempts

nameserver が1つの場合

nameserver が2つの場合

nameserver が3つの場合

timeout 時のドメイン補完

Go の動作確認で使ったコード

ndots:5 の凶悪さを可視化する

Laravelで手軽にログイン認証機能を実装する

1、バージョンを確認する

2、Laravel/uiをインストールする。

3、認証機能を実装する

4、フロントエンド部分を実装する〜完成

番外編:どのようにデータが格納されているか

RaspberryPi 4 Model B で USBポートの電源をON/OFFする リトライ

目標

構成

Per-port power switchingとは

ラズパイ4のUSB構成

事前準備

ファームウェアアップデート

コマンドインストール

HUB確認

推測など

iostat

参考

Manjaro Linuxでログインパスワードを忘れたときの対応

概要

対応手順

ref

無限再起動ループの闇に堕ちたCentOS8君をシングルユーザーモードで復旧

何をやっちゃったのか

よくねーよ！！

じゃあどうするのか

シングルユーザーモード起動方法

ファイルを操作できるようにsysrootを再マウント

蛇足

参考サイトさん

バージョン

Dockerが注目される理由。そもそもDockerとは？その使い方

はじめに

Dockerとは

仮想化サーバーとの違い・長所

Dockerが注目されている理由

Dockerを使う流れ

実際のコマンド入力

おわりに

日付別

タグ一覧

RaspberryPi 4 Model B で USBポートの電源をON/OFFする　リトライ