- 投稿日：2020-02-12T22:47:46+09:00
yumコマンドとAPT系コマンドの違い
yumコマンドとAPT系コマンド(apt-get,apt-cache,aptitude)
よく知らずに使っていた、もしくはよく出てくるなーぐらいに思っていた
yumコマンドとAPT系コマンドについてまとめたいと思います。どちらもLinuxについて調べているでよく出てくるコマンドでパッケージを管理するために使います。
パッケージのインストール
yum install <パッケージ名>
apt-get install <パッケージ名>パッケージの削除
yum erase / remove <パッケージ名>
apt-get remove <パッケージ名>パッケージの検索
yum search <検索ワード>
apt-chche search <検索ワード>また、これらのコマンドに似ているrpmやdpkgといったコマンドも存在します。
これらのコマンドもパッケージを管理することができるのですが、yumコマンドやAPT系コマンドと比べると
低機能で依存性の解決も自分で手動で行うこととなるので今では使う人はほとんどいません。というのもyumコマンドはrpmコマンドを、APT系コマンドはdpkgコマンドをそれぞれ高機能にしたコマンドと
なっているため、使う必要がないのです。それではyumコマンドとapt系コマンドの違いについて説明します。
二つのパッケージ形式
現在のLinuxで主流のパッケージファイル形式は大きく二つに分けられます。
パッケージファイル形式 ディストリビューション パッケージ管理コマンド Red Hat形式(.rpm) Red Hat Enterprise Linux, CentOs rpm、yumコマンド Debian形式(.deb) Debian GNU, Ubuntu dpkg、APT系コマンド yumコマンドとAPT系コマンド、またはrpmコマンドとdpkgコマンドの違いはこのパッケージ形式の違いです。
UnuntuなどのDebian形式のディストリビューションを使っている場合はAPT系コマンド、CentOsなどのRed Hat形式のディストリビューションを使っている場合はyumコマンドを使うことができます。
基本的にapt-getでインストールできるパッケージはyumコマンドでもインストールすることができるので自分の環境にあった方のコマンドを使えばいいです。ただし、パッケージ名が多少異なる場合もあるので気を付けてください。
- 投稿日：2020-02-12T21:55:31+09:00
Intel NUC + SSD 2TB + DRAM 32GBでハイスペックLinuxデスクトップを作ってみた
一昨年のボーナスシーズンにPayPayでMacBook Air 2018を購入した時に購入金額の20%分として付与されていたPayPayポイントを有効活用するべく、昨年9月末の増税前にIntel NUCを購入しました。そして、昨年末のボーナスシーズンにSSDとDRAMも購入し、Linuxデスクトップマシーンを構築したので記念に色々まとめてみることにしました。
今回の自作のあれこれ
- Deep Learningなどの自由研究に使えるGPU搭載マシンが欲しかったので手始めにLinuxマシンを自作してみることにしました。
- 自作初心者なのでマザーボード選びで悩まなくても済む様に、Intelのベアボーンキットを購入することにしました。
- 最近登場したeGPUというのを試してみたかったので、敢えてThundebolt 3に対応したベアボーンを購入しました。
- GPUマシン化はグラフィックカードを購入したら挑戦しようと思います。
部品の購入
参考までに今回購入したパーツの詳細情報を記載します。ベアボーンは消費増税前に買ったのであくまで当時の価格です。
パーツの種類 型番 メーカー 価格 備考 本体 NUC8I7BEH Intel ¥66,000. CPU付属のベアボーン, 支払いには¥44,461.分のPayPayポイントを利用 CPU Core i7 8559U Intel - ベアボーンに付属, 4C8T, 2.7GHz(TB時:4.5GHz) SSD1 NM610(1TB) Lexar ￥11,528.(うち交換保証:￥500.) NVMe SSD OS, ブートローダーインストール用に使用 SSD2 NS100(1TB) Lexar ￥10,428.(うち交換保証:￥500.) /home用ドライブとして使用 DRAM CT2K16G48FD8266 DDR4 2666(32GB) crucial ￥16,918. マザーボードの最大搭載可能メモリ容量上限値が32GBのため ディスプレイ
21.5inch WidePH15997426 PHILIPS ￥8,980. HDMIx2+D-SUB搭載
NTT-X Storeのお正月セールで購入キーボード K380 Logicool ￥3,500. PCを3台まで登録出来るので購入。マウスは既に有るものを流用 ヒートシンク SS-M2S-HS02 長尾製作所 ￥1,359. NVMe SSD冷却用に購入 電源ケーブル - - ￥0. ベアボーン付属のACアダプタには電源コードが付属していないため、不要なタブレットPCのACアダプタより拝借 合計費用: ￥107,185.(PayPay考慮時: ￥62,724.)
(追記) Intel NUC8I7BEHの拡張性
今回使用したベアボーンは手のひらサイズですが、拡張性はそこそこ有ると思います。(以下の写真は粗実物大)
仕様 USB3.0 x 4(前面x2, 背面x2) Thunderbolt 3ポート(背面) HDMIポート(背面) Intel® Ethernet Connection I219-V(背面) オーディオポート（ヘッドフォン・マイク対応、前面) Intel® Wireless-AC 9560 + Bluetooth 5.0(内蔵) マイクロSDカードスロット(左側面) PCの組み立て
ベアボーンに購入した部品を取り付ける作業は0から自作するのと比較してとても簡単です。ベアボーンを開けてマザーボード上に部品を取り付けるだけです。
OSセットアップ
OSのセットアップを行い、組み立てたPCが動作できる様にします。今回はUbuntu 18.04 LTS Desktop版をインストールしました。最初はServer版をインストールしようと試みましたが、SSDがどうしても認識されなかったのと、GUIも使いたかったのでDesktop版をインストールすることにしました。パーティション構成は以下の様にしました。
パーティション 容量 備考 efi 1GB UEFI用パーティション。従来の/bootに代わるパーティション / 300GB /rootなどが入るパーティション /usr 344GB インストールするアプリケーションが格納されるパーティション /var 344GB 当初は20GBぐらいにするつもりが、KVMで重要な役割を果たすパーティションと判明したため増量 swap 10GB /~swapはNVMe SSDに割当 /home 1TB SATA SSDをまるまる1台/home用に割当 Ubuntuのパッケージマネージャー
Ubuntuのパッケージマネージャーはapt-getが一般的ですが、最新版のUbuntuではaptが推奨の様です。aptitudeというパッケージマネージャーも有りますが、Ubuntu 18.04では非推奨となっている様です。今までaptitudeを使っていましたが、これを機会にaptに乗り換えることにします。
参考: http://ultra-genma.hateblo.jp/entry/2019/04/08/233718ufwの設定
ファイアウォールを設定しました。ufwが既にインストールされていた為、設定しました。16.04までは自分でインストールする必要が有りましたが、自動的にインストールされる様です。
参考: ufwの基本操作mDNSの設定
同一ネットワーク内からのSSHアクセスなら
HOST_NAME.localでアクセス可能となり、IPアドレスの入力が不要になります。参考: mDNSを設定して、いちいちIPアドレスを打ち込むのをやめよう。
まとめ
Intel NUCを用いたLinuxマシーンを自作しました。このスペックで10万円ちょっとならかなりコストパフォーマンスの良い自作になったのではないかと思います。折角リソースが潤沢なマシンを作ったので、KVMベースでマルチノードKubernetesの構築やThudebolt 3に対応していることを生かしてeGPUを取り付けてGPUマシン化に挑戦したいと思います。
今後の改良予定(要予算との相談)
- DockerをインストールしてJupyterLabサーバー化
- R Studio ServerをDockerで立ち上げ
- KVMベースのマルチノードKubernetesの構築に挑戦
- eGPUをドッキングしてGPUマシーン化
- TensorFlowやPyTorchをGPU動作させられるマシーンに
Reference
https://eng-entrance.com/linux-partition
https://ark.intel.com/content/www/jp/ja/ark/products/137979/intel-core-i7-8559u-processor-8m-cache-up-to-4-50-ghz.html
- 投稿日：2020-02-12T21:48:09+09:00
Apache2系をソースからインストールする
UbnutuにApache2.4をソースからインストールする
専門学校の卒業制作でApacheを扱ったので備忘録的に書いておく
Ubuntuですら触ったのは初めてなので多々抜けている点もあるかと思われOS
Ubuntu18.04LTS
参考記事
https://www7390uo.sakura.ne.jp/wordpress/archives/467
https://bty.sakura.ne.jp/wp/archives/149
https://www.skyarch.net/blog/?p=9543必要なもの
1.GCC(Cコンパイラ)
2.pcre-8.39
3.apr-1.7.0
4.apr-util-1.6.1
5.httpd-2.4.41コンパイルとインストール
上記のものを/usr/local/srcにダウンロードして解凍
ダウンロードの際は
$ wget (URL)解凍は
$ tar zxvf (ファイル名)解凍後、各ディレクトリに入って
$ ./configure
$ make || make installと実行していきます。
注意点その1
expat.hというライブラリが足りないといわれたので
ここ
からダウンロードします。こいつをインストールすればいけるはず。注意点その2
apr-utilの./configureを実行する際にオプションで
./configure --with-apr=/usr/local/apr
とつけてやる
注意点その3
httpd-2.4.41の./configureもオプションで
./configure --with-pcre=/usr/local/src/pcre-8.39/pcre-config --with-apr=/usr/local/src/apr-1.7.0 --with-apr-util=/usr/local/src/apr-util-1.6.1
とつけてやる
注意点その4
インストール後、いざ起動しようとするとライブラリのパスを通せというメッセージが出てきたため、
export LD_LIBRARY_PATH="/usr/local/lib"
これで実行できるようになる。
- 投稿日：2020-02-12T21:48:09+09:00
Apache2.4.41をソースからインストールする
専門学校の卒業制作で初めてApacheを扱ったので備忘録的なアレを書いておく
Ubuntuですら触ったのは初めてなので多々抜けている点もあるかと思われOS
Ubuntu18.04LTS
参考記事
https://www7390uo.sakura.ne.jp/wordpress/archives/467
https://bty.sakura.ne.jp/wp/archives/149
https://www.skyarch.net/blog/?p=9543必要なもの
1.GCC(Cコンパイラ)
2.pcre-8.39
3.apr-1.7.0
4.apr-util-1.6.1
5.httpd-2.4.41GCCのインストール
サクっとaptコマンドで
$ apt-get install build-essentialコンパイルとインストール
上記のものを/usr/local/srcにダウンロードして解凍
ダウンロードの際は
$ wget (URL)解凍は
$ tar zxvf (ファイル名)解凍後、各ディレクトリに入って
$ ./configure
$ make || make installと実行していきます。
注意点その1
expat.hというライブラリが足りないといわれたので
ここ
からダウンロードします。こいつをインストールすればいけるはず。注意点その2
apr-utilの./configureを実行する際にオプションで
$ ./configure --with-apr=/usr/local/aprとつけてやる
注意点その3
httpd-2.4.41の./configureもオプションで
$./configure --with-pcre=/usr/local/src/pcre-8.39/pcre-config --with-apr=/usr/local/src/apr-1.7.0 --with-apr-util=/usr/local/src/apr-util-1.6.1とつけてやる
注意点その4
インストール後、いざ起動しようとするとライブラリのパスを通せというメッセージが出てきたため、
$ export LD_LIBRARY_PATH="/usr/local/lib"これで実行できるようになる。
- 投稿日：2020-02-12T17:50:18+09:00
固まったRailsのローカルアプリケーションサーバ（Puma）を強制終了する
Railsを使用して開発していると、Pumaが固まって
Ctrl+CでもPumaを終了できないことがあります。そんな時は以下のコマンドで解決！pkill -9 -f 'puma 4.3'上記のコマンドを叩いた後、ターミナルにて以下のように表示されていれば強制終了成功です。
Killed: 9
- 投稿日：2020-02-12T17:50:18+09:00
固まったRailsのローカルWebサーバ（Puma）を強制終了する方法
Railsを使用して開発していると、Pumaが固まって
Ctrl+CでもPumaを終了できないことがあります。そんな時は以下のコマンドで解決！pkill -9 -f 'puma 4.3'上記のコマンドを叩いた後、ターミナルにて以下のように表示されていれば強制終了成功です。
- 投稿日：2020-02-12T17:50:18+09:00
固まったRailsのローカルアプリケーションサーバ（Puma）を強制終了する方法
Railsを使用して開発していると、Pumaが固まって
Ctrl+CでもPumaを終了できないことがあります。そんな時は以下のコマンドで解決！pkill -9 -f 'puma 4.3'上記のコマンドを叩いた後、ターミナルにて以下のように表示されていれば強制終了成功です。
Killed: 9
- 投稿日：2020-02-12T17:13:00+09:00
Shellのコマンド履歴に任意のコマンドを残したい
Problem
Interactive filterを使っていたりするとコマンドよりも結果をhistoryに残した方が便利なケースが度々あります。
# 例：fzfで選択したファイルをvimで開く alias v='_vim_fzf' _vim_fzf () { local file file=$(fzf +m -q "$1") && vim "$file" }上記の場合、historyを遡っても選んだファイルは出てきません。
Solution
Bashでは
history -sを使います。_vim_fzf () { local file file=$(fzf +m -q "$1") && history -s "vim $file" && vim "$file" }このように書き直すと、
vコマンドの代わりにvim [選んだファイル]が履歴に残るのでCtrl-RやCtrl-Pでファイルを再び開くことが可能になります。Further Work (Zsh)
Zshでは
print -sが相当するそうです。$ print -s "alternative command" $ history # ... # 99 print -s "alternative command" # 100 alternative command問題は上のように
- 投稿日：2020-02-12T14:03:03+09:00
ガストで Linux で Wifi 接続ができない状況
ガストで Linux で Wifi 接続ができない状況の報告です。
テストしたのは、Arch LInux です。
$ uname -a Linux iwata 5.5.2-arch1-1 #1 SMP PREEMPT Tue, 04 Feb 2020 18:56:18 +0000 x86_64 GNU/Linux/etc/netctl/wlp2s0-free_atDescription='Automatically generated profile by wifi-menu' Interface=wlp2s0 Connection=wireless Security=none ESSID=.Wi2_Free_at_\[SK.GROUP\] IP=dhcp使ったコマンド
sudo netctl start wlp2s0-free_atUbuntu 19.10 でも wifi の接続を試みましたが失敗しました。
Android では wifi 接続ができます。
- 投稿日：2020-02-12T13:50:41+09:00
Linux 上で Objective-C 2.0 の開発環境を整える
トレンドが Swift に移って久しく，近年は Objective-C に関心を持つ人が減っていますが，Linux 上で Objective-C の開発環境を整える方法についてまとめてみました。
Docker 上の Ubuntu 18.04 および 19.10 で動作確認しています。Dockerfile の
ENVとRUNの内容を取り出せば，実機でも動くでしょう。Objective-C 1.0 でよいなら……
昔ながらの Objective-C 1.0 でよいなら，apt で入手できる出来合いのパッケージをインストールすれば，比較的容易に Clang 9 による Objective-C の開発環境を整えられます。
DockerfileFROM ubuntu:19.10 RUN set -x \ && apt update \ && apt upgrade -y \ && DEBIAN_FRONTEND=noninteractive apt install -y tzdata \ && apt install -y clang-9 make gobjc-9 gnustep-devel \ && apt autoremove -y \ && apt clean \ && rm -rf /var/cache/apt/archives/* /var/lib/apt/lists/* # Set alias RUN echo 'alias clang-objc="clang-9 \$(gnustep-config --objc-flags) \$(gnustep-config --objc-libs) -lgnustep-base -I/usr/lib/gcc/x86_64-linux-gnu/9/include"' > ~/.bashrc CMD ["/bin/bash"]本質部は
$ apt install -y clang-9 make gobjc-9 gnustep-develです。また，
~/.bashrcにalias clang-objc="clang-9 \$(gnustep-config --objc-flags) \$(gnustep-config --objc-libs) -lgnustep-base -I/usr/lib/gcc/x86_64-linux-gnu/9/include"と定義してあります。これにより，この Docker コンテナ内で
$ clang-objc -o hoge hoge.m $ ./hogeなどとすることで簡単に Objective-C のソース
hoge.mをコンパイル・実行できます。Objective-C 2.0 のフル機能を使いたいなら……
- Automatic Reference Counting (ARC)
- Blocks
- Dot Notation
- Object Literal
- Object Subscripting
- Fast Enumeration
- Lightweight Generics
- Grand Central Dispatch (GCD)
といった Modern Objective-C の機能をフルに使いたい場合は，GNUstep の libobjc2 をセットアップせねばなりません。これは apt でインストールできないので，ソースからビルドする必要があります。これがなかなか大変です。plaurent 氏の GitHub レポジトリが大変参考になりました。ビルド手順を Dockerfile にまとめると次のようになります。
DockerfileFROM ubuntu:19.10 ENV CC clang-9 ENV CXX clang++-9 ENV CXXFLAGS -std=c++11 ENV RUNTIME_VERSION gnustep-2.0 ENV PKG_CONFIG_PATH /usr/local/lib/pkgconfig ENV LD /usr/bin/ld.gold ENV LDFLAGS "-fuse-ld=/usr/bin/ld.gold -L/usr/local/lib" WORKDIR /GNUstep-build RUN set -x \ && apt update \ && apt upgrade -y \ && apt install -y git sudo clang-9 clang++-9 build-essential wget \ subversion cmake libffi-dev libxml2-dev \ libgnutls28-dev libicu-dev libblocksruntime-dev libkqueue-dev libpthread-workqueue-dev autoconf libtool \ libjpeg-dev libtiff-dev libffi-dev libcairo-dev libx11-dev libxt-dev libxft-dev \ && apt autoremove -y \ && apt clean \ && rm -rf /var/cache/apt/archives/* /var/lib/apt/lists/* # Build GNUstep make RUN set -x \ # # Checkout tools-make && git clone https://github.com/gnustep/tools-make.git \ # # Build GNUstep make && cd tools-make \ && CC=${CC} ./configure \ --with-layout=gnustep \ --disable-importing-config-file \ --enable-native-objc-exceptions \ --enable-objc-arc \ --enable-install-ld-so-conf \ --with-library-combo=ng-gnu-gnu \ && make -j8 \ && sudo -E make install \ && . /usr/GNUstep/System/Library/Makefiles/GNUstep.sh \ && echo ". /usr/GNUstep/System/Library/Makefiles/GNUstep.sh" >> ~/.bashrc \ && echo "export RUNTIME_VERSION=gnustep-2.0" >> ~/.bashrc \ && echo 'export CXXFLAGS="-std=c++11"' >> ~/.bashrc \ && cd .. \ # # Build libdispatch # # Checkout swift-corelibs-libdispatch && git clone https://github.com/apple/swift-corelibs-libdispatch \ && cd swift-corelibs-libdispatch \ && git checkout swift-5.1.1-RELEASE \ # # Build libdispatch && rm -Rf build \ && mkdir build \ && cd build \ && cmake .. \ -DCMAKE_C_COMPILER=${CC} \ -DCMAKE_CXX_COMPILER=${CXX} \ -DCMAKE_BUILD_TYPE=Release \ -DUSE_GOLD_LINKER=YES \ && make \ && sudo -E make install \ && sudo ldconfig \ && cd ../.. \ # # Build libobjc2 # # Checkout libobjc2 && git clone https://github.com/gnustep/libobjc2.git \ && cd libobjc2 \ && git submodule init \ && git submodule sync \ && git submodule update \ # # Build libobjc2 && rm -Rf build \ && mkdir build \ && cd build \ && cmake .. \ -DCMAKE_C_COMPILER=${CC} \ -DCMAKE_CXX_COMPILER=${CXX} \ -DCMAKE_ASM_COMPILER=${CC} \ -DTESTS=OFF \ && cmake --build . \ && sudo -E make install \ && sudo ldconfig \ && cd ../.. \ # # Build GNUstep make second time && cd tools-make \ && CC=${CC} ./configure \ --with-layout=gnustep \ --disable-importing-config-file \ --enable-native-objc-exceptions \ --enable-objc-arc \ --enable-install-ld-so-conf \ --with-library-combo=ng-gnu-gnu \ && make -j8 \ && sudo -E make install \ && . /usr/GNUstep/System/Library/Makefiles/GNUstep.sh \ && cd .. \ # # Build GNUstep base # # Checkout libs-base && git clone https://github.com/gnustep/libs-base.git \ # # Build GNUstep base && cd libs-base \ && ./configure \ && make -j8 \ && sudo -E make install \ && cd .. # For GUI programming # # Build GNUstep GUI Library RUN set -x \ && . /usr/GNUstep/System/Library/Makefiles/GNUstep.sh \ # # Checkout libs-gui && git clone https://github.com/gnustep/libs-gui.git \ # # Build GNUstep GUI Library && cd libs-gui \ && ./configure \ && make -j8 \ && sudo -E make install \ && cd .. \ # # Build GNUstep GUI Backend # # Checkout libs-back && git clone https://github.com/gnustep/libs-back.git \ # # Build GNUstep GUI Backend && cd libs-back \ && ./configure \ && make -j8 \ && sudo -E make install \ && cd .. WORKDIR /workdir # Clean build directory RUN rm -rf /GNUstep-build # Set alias RUN echo 'alias clang-objc="\${CC} \$(gnustep-config --objc-flags) \$(gnustep-config --objc-libs) -fobjc-arc -lobjc -ldispatch -lgnustep-base"' >> ~/.bashrc CMD ["/bin/bash"]長いビルド手順でしたね……。最後に
~/.bashrcにalias clang-objc="\${CC} \$(gnustep-config --objc-flags) \$(gnustep-config --objc-libs) -fobjc-arc -lobjc -ldispatch -lgnustep-base"と設定してありますので，この Docker コンテナ内で
$ clang-objc -o hoge hoge.m $ ./hogeなどとすることで簡単に Objective-C 2.0 のソース
hoge.mをコンパイル・実行できます。Dockerfile およびテストファイル一式
今回作成した Dockerfile およびテスト用 Objective-C ソースの一式は GitHub レポジトリ にアップしておきました。
$ docker run --rm -it -v $(pwd):/workdir doratex/clang9-objc2:latest /bin/bash # cd test # ./test_all.shとすることで，様々な Objective-C 2.0 の機能をテストできます。（ただしテストのうち最後の GUI のテストは X Window System のサーバとつながっていないと動きません。）
Docker イメージ
今回作成した Docker イメージは Docker Hub のレポジトリ にアップしてあります。
$ docker pull doratex/clang9-objc2:ubuntu1910などとすれば使えます。
- 投稿日：2020-02-12T12:00:17+09:00
Teamviewer for Linuxの導入手順（CentOS)
CentOS7へTeamViewerをいれたのでメモ
X-Windowのインストール
# yum groupinstall -y "GNOME Desktop"TeamViewer インストール
# yum install -y epel-release # yum install https://download.teamviewer.com/download/linux/teamviewer.x86_64.rpmTeamViewer セットアップ
# teamviewer setupTeamViewerのアカウントを聞かれる。
アカウントでログインすると、CentOSのホストのログイン確認メールがアカウントのメールアドレスへ届く
承認して再度ログインするTeamViewer 自動起動設定
# teamviewer daemon enableメモ
- 有償版TeamViewerでしか試していないので無償版で使っているひとは確認必要
- Windows版TeamViewerからLinux版TeamViewerへの接続をしようとすると、謎アルゴリズムで個人利用じゃないだろと言われる。
- 年払いライセンスなのでいいお値段に見えるけど、買うと超便利
- 投稿日：2020-02-12T11:54:43+09:00
apacheなどのファイル形式のログをsyslogとしてリモートに転送する
はじめに
いろんなサーバから吐き出されるファイル形式のログをリモートのsyslogに集約しています。
ログを吐くサーバ側での設定は、必要最低限の設定として、加工やらなんやらはリモートで実施するようにします。apacheのsyslogを別ホストに転送したかった。ので、メモ。
設定したいもの
今回の事例では、トラフィック収集ツールの cacti が稼働しているサーバから
apacheのアクセスログとcactiログをリモートのsyslogサーバへ転送します。syslog転送先ホストの設定
- syslog(同じdocker networkにいるsyslogサーバ）
- 10.10.254.10.112
これらにログを送付するために、rsyslogの設定ファイルに追加します。
/etc/rsyslog.conf--------8<----(snip)----8<-------- module(load="imfile") input(type="imfile" file="/var/log/httpd/access_log" tag="pseudolog_httpd_access_log" facility="local0" severity="notice") :syslogtag, isequal, "pseudolog_httpd_access_log" @syslog:514 & @10.254.10.112:514 input(type="imfile" file="/usr/share/cacti/log/cacti.log" tag="pseudolog_cacti_log" facility="local0" severity="notice") :syslogtag, isequal, "pseudolog_cacti_log" @syslog:514 & @10.254.10.112:514 --------8<----(snip)----8<--------この例では、514/udpで送信してますが、
@@address:portと（@を２つ並べる）すると、TCPの転送になります。
同一のdockerネットワークに所属させているため、ホスト名syslogで転送可能な状態となっています。
ほかのファイルに吐かれているログも上記同様に指定すると、転送できます。rsyslog.conf（設定ファイル）の書き方# モジュールを読み込む。これは最初に１回記載すればよいです。 module(load="imfile") # input() の箇所でsyslogへ入力するソース（今回はimfile）を指定します。 # type:ソースの種別です。今回はimfileモジュール経由 # file:imfileで検知させる対象ファイル名 # tag:転送する際のsyslogタグを指定 # facility:転送する際のfacilityを指定 # severity:転送する際のseverityを指定 input(type="imfile" file="/var/log/httpd/access_log" tag="pseudolog_httpd_access_log" facility="local0" severity="notice") # どのような条件に場合に、どのような処理をするか、を記載していきます # 下記の場合は、 # 条件：syslogtagがpseudolog_httpd_access_logの場合 # 処理：syslogというホスト名に対して、UDP:514ポートで転送 # 条件に対して、複数の処理を行いたい場合には、直後の行に & で処理を記載します。 :syslogtag, isequal, "pseudolog_httpd_access_log" @syslog:514 & @10.254.10.112:514設定したら、サービスの再起動
systemctl rsyslog restartsyslog転送先ホストで確認
Feb 11 21:58:22,Feb 11 21:58:22,VMinfraserv05,pseudolog_httpd_access_log,5,16, 10.254.10.11 - - [11/Feb/2020:21:58:19 +0900] "GET /cacti/graph_json.php?rra_id=0&local_graph_id=36&graph_start=1581339497&graph_end=1581425897&graph_height=200&graph_width=700 HTTP/1.1" 200 35392 "http://cacti/cacti/graph_view.php?action=tree&node=tbranch-5&host_id=3&site_id=-1&host_template_id=-1&hgd=&hyper=true" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36" Feb 11 21:58:22,Feb 11 21:58:22,VMinfraserv05,pseudolog_httpd_access_log,5,16, 10.254.10.11 - - [11/Feb/2020:21:58:19 +0900] "GET /cacti/graph_json.php?rra_id=0&local_graph_id=151&graph_start=1581339497&graph_end=1581425897&graph_height=200&graph_width=700 HTTP/1.1" 200 53103 "http://cacti/cacti/graph_view.php?action=tree&node=tbranch-5&host_id=3&site_id=-1&host_template_id=-1&hgd=&hyper=true" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36" Feb 11 21:58:32,Feb 11 21:58:32,VMinfraserv05,pseudolog_httpd_access_log,5,16, ::1 - - [11/Feb/2020:21:58:28 +0900] "OPTIONS * HTTP/1.0" 200 - "-" "Apache/2.4.6 (CentOS) PHP/5.4.16 (internal dummy connection)" Feb 11 22:00:12,Feb 11 22:00:12,VMinfraserv05,pseudolog_cacti_log,5,16, 2020/02/11 22:00:08 - SYSTEM STATS: Time:6.4693 Method:spine Processes:1 Threads:1 Hosts:15 HostsPerProcess:15 DataSources:271 RRDsProcessed:143 Feb 11 22:00:12,Feb 11 22:00:12,VMinfraserv05,pseudolog_cacti_log,5,16, 2020/02/11 22:00:08 - SNMPAGENT WARNING: No notification receivers configured for event: cactiNotifyDeviceFailedPoll (CACTI-MIB), severity: medium Feb 11 22:00:12,Feb 11 22:00:12,VMinfraserv05,pseudolog_cacti_log,5,16, 2020/02/11 22:00:08 - POLLER: Poller[1] WARNING: You have 4 Devices with bad SNMP Indexes. Devices: Device[1], Device[4], Device[15], Device[17] totalling 17 Data Sources. Please Either Re-Index, Delete or Disable these Data Sources.出典
https://knowledge.sakura.ad.jp/8969/
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/system_administrators_guide/s1-basic_configuration_of_rsyslog
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/system_administrators_guide/s1-using_rsyslog_modules
- 投稿日：2020-02-12T08:04:22+09:00
Docker Swarmで学ぶサービスメッシュ
はじめに
本記事はDocker Swarmでクラスタを構築し、サービスメッシュについて学びます。
環境はAWSのELB（Elastic Load Balancing）と、EC2（Amazon EC2）インスタンス2台を使用し、Docker Swarmのクラスタを構築します。
Kubernetesと比較した際にDocker Swarmを導入するメリットは、導入コストが低いことです。Docker SwarmはKubernetesに比べてハードルが低いため、本番環境にコンテナ技術を導入しようとしているシステムには最適だと考えます。
Docker Swarmを通してサービスメッシュの意義を体感しましょう。
Docker Swarm
Docker Swarmは、Docker社が提供するオーケストレーションツールです。
Docker Swarmを使用することで複数のホストを集約し、簡単にコンテナのデプロイとスケールが実現できます。
Docker Swarmはマネージャとノードで構成され、Swarmは群れを意味します。
Docker Swarのクラスタを構築するためには、以下の作業が必要です。
- マネージャとノードにDockerをインストールする。
マネージャとノード間で通信ができるように、ファイアウォールで必要な通信を許可する。
ファイアウォールで許可するルール
ポート番号 用途 2377/tcp クラスタ管理用の通信 4789/udp オーバーレイ・ネットワーク 7946/tcp ノード間通信 7946/udp ノード間通信 サービスメッシュ
サービスメッシュはマイクロサービスアーキテクチャを前提とし、アプリケーション間で通信を制御する仕組みを提供します。この制御された通信はメッシュの様に編みがけになっているため、信頼性を向上します。
例として2台構成のホストの場合、通常のアクセスパスは以下になります。
ブラウザでロードバランサーのDNS名にアクセスすると、HTTPリクエストを受け付けたロードバランサーは、ラウンドロビンでバックエンドであるホストの公開ポートにHTTPリクエストを振り分けます。
例えば、片方のホストで何らかの障害が発生し、コンテナがダウンした場合でも以下の経路により、サービスを継続することができます。
要約すると、単純にホストレベルでアプリケーションを分ける構成の場合は、片方のホストに何らかの障害が発生したときにサービスの提供ができなくなります。よって、コンテナ技術を活用し、サービスメッシュにすることで単一障害点をなくすことができます。
Docker Swarm構築
Docker Swarmの構築手順について記載します。
Docker Swarmの構築は、マネージャ、ノードの順に作業を行います。本記事の例ではweb1がマネージャ、web2がノードになり、Nginxのイメージを使用してデプロイします。
前提条件としてDockerは既にインストールされた状態で、上記で解説したファイアウォールも許可されていることとします。また、本記事では最低限の構成としているため、マネージャ1台、ノード1台になります。
マネージャ
まずはじめに、Docker Swarmの初期化を行います。
docker swarm initコマンドを実行することでSwarmモードが有効になります。複数IPアドレスを持つ場合は、他のノードとの通信で使用するインターフェースのIPアドレスを
advertise-addrの引数に指定します。
- Docker Swarmの初期化
# docker swarm init --advertise-addr ＜IPアドレス＞Swarm initialized: current node (zirc78nsch77ox8di6021ux4n) is now a manager. To add a worker to this swarm, run the following command: docker swarm join --token SWMTKN-1-459p0pkyqgxgkhaggjhavd419ldujenqttm1mqmwup0qz9m5qv-1kj3jy6ozwrr2fkj1qvas294a ＜マネージャのIPアドレス＞:2377 To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.コマンド実行後、出力結果の
docker swarm join --token SWMTKN-1-（略） ＜マネージャのIPアドレス＞:2377を控えます。
- node確認
# docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION zirc78nsch77ox8di6021ux4n * web1 Ready Active Leader 18.09.9-ceマネージャの場合は、MANAGER STATUSにLeaderと出力されます。
- ネットワーク確認
# docker network lsNETWORK ID NAME DRIVER SCOPE 53703efd3d07 bridge bridge local aacf6f5e0eb4 docker_gwbridge bridge local 1f0d0e4ae3e7 host host local xip5tlqmokpb ingress overlay swarm 2d36f1c8c80f none null localSwarmの初期化を行うと新たに２つのネットワーク（docker_gwbridge、ingress）が作成されます。
ノード
次にノードをDocker Swarmのクラスタに参加させるため、ノード側で以下のコマンドを実行します。
--tokenの引数にしている値は例になります。上記docker swarm initコマンドの出力結果をコピーしてペーストすれば大丈夫です。なお、マネージャ側で
docker swarm join-token workerコマンドを実行することで、トークンの再表示もできます。
- クラスタ参加
# docker swarm join --token SWMTKN-1-（略） ＜マネージャのIPアドレス＞:2377This node joined a swarm as a worker.マネージャ側で確認のため、再度、
docker node lsコマンドを実行すると、nodeが認識されていることが確認できます。
- node確認
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION zirc78nsch77ox8di6021ux4n * web1 Ready Active Leader 18.09.9-ce n2o22ptdmyhan8qg0ijmo0qn5 web2 Ready Active 18.09.9-ceDocker Swarmのデプロイ
本記事では管理しやすいdocker-commposeでデプロイします。
また、docker service createコマンドでもデプロイできます。serviceやstackの説明については割愛します。デプロイ作業はマネージャ側で行います。
任意のディレクトリに移動し、以下のdocker-commpose.ymlファイルを作成します。
- docker-commpose.yml
version: "3" services: web: image: nginx deploy: replicas: 2 #resources: # limits: # cpus: "0.1" # memory: 100M restart_policy: condition: on-failure ports: - "80:80" networks: - webnet networks: webnet:
docker-commpose.ymlファイル作成後、以下のコマンドを実行し、デプロイします。
testは例となるため、任意の名前を指定します。
# docker stack deploy -c docker-commpose.yml testUpdating service test_web (id: egubeieuri00rzmm9imsna93o)デプロイ後、以下のコマンドでサービスの状態が確認できます。
REPLICASは2となっているので、2つのコンテナが起動しています。
# docker service lsID NAME MODE REPLICAS IMAGE PORTS r04mfg1se3nh test_web replicated 2/2 nginx:latest *:80->80/tcpマネージャとノード側で
docker container ps -aコマンドを実行すると、コンテナが起動しているのが確認できます。
- マネージャ側
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 4a26c3ca6df7 nginx:latest "nginx -g 'daemon of…" 3 seconds ago Up 2 seconds 80/tcp test_web.1.mnnz40tdykzd2intwz5hf68bs
- ノード側
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 614c19349bf0 nginx:latest "nginx -g 'daemon of…" 2 minutes ago Up 2 minutes 80/tcp test_web.2.6om5oazbavassohd4akucbum2Docker Swarmの動作確認
Docker Swarmの動作確認を行います。
ブラウザからロードバランサーのDNS名にアクセスを行い、正常に負荷分散されることを確認します。
- ロードバランサーのDNS名にアクセス
コンテナのログを確認すると、ラウンドロビンで負荷分散されているのが確認できます。
CONTAINER IDはdocker container ps -aのコマンドで確認します。
# docker logs -f ＜CONTAINER ID＞10.255.0.3 - - [06/Feb/2020:14:20:51 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36" "＜アクセス元のグローバルIP＞"試しにweb2上（ノード側）で稼働しているコンテナを停止します。
# docker stop ＜CONTAINER ID＞CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 423f673b0513 nginx:latest "nginx -g 'daemon of…" 19 hours ago Exited (0) 5 seconds ago test_web.2.kc7yypyasgvjtolsb1zwmhjoyこのときweb2上でコンテナは稼働していません。
ロードバランサーのDNS名にアクセスできることを確認します。
例としてブラウザから停止したweb2の公開IPにアクセスします。
Web1（マネージャ）上のコンテナのアクセスログに、停止したweb2（ノード）の公開IPに対するアクセスが確認できます。
10.255.0.3 - - [07/Feb/2020:02:19:01 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36" "-"停止したweb2（ノード側）のローカルからも、以下のコマンドを実行することでコンテナにアクセスができます。
# curl localhost 80<!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html> curl: (7) Couldn't connect to serverweb1（マネージャ）のログでは以下の様に出力されます。
10.255.0.2 - - [07/Feb/2020:02:41:47 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.61.1" "-"web1（マネージャ）で4789ポートをダンプして見ていると、オーバーレイ・ネットワークの通信を見ることができます。
# tcpdump -nli eth0 port 4789 -AvDocker Swarmのスケール
既にサービスが起動している状態で、以下のコマンドを実行することでスケールができます。以下のコマンドはコンテナの数を4コンテナに変更しています。
# docker service scale test_web=4test_web scaled to 4 overall progress: 4 out of 4 tasks 1/4: running [==================================================>] 2/4: running [==================================================>] 3/4: running [==================================================>] 4/4: running [==================================================>] verify: Service convergedスケール後、
docker container ps -aコマンドを実行すると、コンテナが増えていのが分かります。CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 41962946aa48 nginx:latest "nginx -g 'daemon of…" 3 minutes ago Up 3 minutes 80/tcp test_web.4.pytl36ejcd81ybthisxfo47br 423f673b0513 nginx:latest "nginx -g 'daemon of…" 7 hours ago Up 7 hours 80/tcp test_web.2.kc7yypyasgvjtolsb1zwmhjoyデプロイ時はサーバ1台ずつに対してアプリケーション資産の入れ替えを行う必要がなく、マネージャ1台で済みます。
Docker Swarmの性質
Docker Swarmは冪等性を持っています。
具体的には、Docker Swarmは指定したreplicas数のコンテナを維持するため、クラスタ化している片方のホストがダウンした場合は、片方のホストでコンテナを起動します。
以下は
docker container ps -aコマンドの出力になります。
例としてweb1とweb2でそれぞれコンテナが起動しています。
- web1
e5ccbfa9739b nginx:latest "nginx -g 'daemon of…" 3 minutes ago Up 3 minutes 80/tcp test_web.1.mrgkhbd7juer72v6bv0l42fxq
- web2
4820c7bbe9c1 nginx:latest "nginx -g 'daemon of…" 3 minutes ago Up 3 minutes 80/tcp test_web.2.wfe1n11s8940rdl8r1c47o6ncweb2のホストを停止しました。web2のダウンを検知すると、web1上でコンテナを作成します。
0a88f53039a3 nginx:latest "nginx -g 'daemon of…" 5 seconds ago Created test_web.2.p06zas3c3kt9ekjojhhfnl3co e5ccbfa9739b nginx:latest "nginx -g 'daemon of…" 4 minutes ago Up 4 minutes 80/tcp test_web.1.mrgkhbd7juer72v6bv0l42fxqweb1上でコンテナが2台起動しています。
0a88f53039a3 nginx:latest "nginx -g 'daemon of…" 37 seconds ago Up 31 seconds 80/tcp test_web.2.p06zas3c3kt9ekjojhhfnl3co e5ccbfa9739b nginx:latest "nginx -g 'daemon of…" 5 minutes ago Up 5 minutes 80/tcp test_web.1.mrgkhbd7juer72v6bv0l42fxqDocker Swarm解除
Docker Swarmの解除方法について記載します。
先にマネージャ側で以下のコマンドを実行し、サービスの削除を行いす。
# docker service rm test_webtest_web次にノード、マネージャの順に作業を行います。
ノード
- ノードの切り離し
# docker swarm leaveNode left the swarm.マネージャ
ノードのSTATUSがDOWNになったことを確認します。
- node確認
# docker node lsID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION zirc78nsch77ox8di6021ux4n * web1 Ready Active Leader 18.09.9-ce n2o22ptdmyhan8qg0ijmo0qn5 web2 Down Active 18.09.9-ceノードを削除します。オプションの引数には、ノード名を指定します。
- node削除
# docker node rm --force web2web2マネージャからノードが認識されなくなったことを確認します。
- node確認
# docker node lsID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION zirc78nsch77ox8di6021ux4n * web1 Ready Active Leader 18.09.9-ce最後にマネージャ自身を切り離します。
- マネージャの切り離し
# docker swarm leave --forceNode left the swarm.Docker Swarm解体
Docker Swarmを使用しない場合は、マネージャ側で以下の作業を行います。
ノードが存在しないことを確認します。
- node確認
# docker node lsError response from daemon: This node is not a swarm manager. Use "docker swarm init" or "docker swarm join" to connect this node to swarm and try again.Docker Swarmで作成されたネットワークが削除されたことを確認します。docker_gwbridgeのネットワークは残っています。
# docker network lsNETWORK ID NAME DRIVER SCOPE 987cfc73d87c bridge bridge local aacf6f5e0eb4 docker_gwbridge bridge local 1f0d0e4ae3e7 host host local 2d36f1c8c80f none null local以下のコマンドを実行し、使用していない全てのリソース削除します。
- リソース削除
# docker system pruneWARNING! This will remove: - all stopped containers - all networks not used by at least one container - all dangling images - all dangling build cache Are you sure you want to continue? [y/N] y Deleted Networks: docker_gwbridge Deleted Images: untagged: nginx@sha256:ad5552c786f128e389a0263104ae39f3d3c7895579d45ae716f528185b36bc6f deleted: sha256:2073e0bcb60ee98548d313ead5eacbfe16d9054f8800a32bedd859922a99a6e1 deleted: sha256:a3136fbf38691346715cac8360bcdfca0fff812cede416469653670f04e2cab0 deleted: sha256:99360ffcb2da18fd9ede194efaf5d4b90e7aee99f45737e918113e6833dcf278 deleted: sha256:488dfecc21b1bc607e09368d2791cb784cf8c4ec5c05d2952b045b3e0f8cc01e untagged: nginx@sha256:70821e443be75ea38bdf52a974fd2271babd5875b2b1964f05025981c75a6717 deleted: sha256:5ad3bd0e67a9c542210a21a3c72f56ef6387cf9b7f4c2506d2398d55a2593ed0 deleted: sha256:b69e2ed46519bc33e7c887967e4f61a2ee53aef165b70f75e208937fb42e7b4c deleted: sha256:4cb7f732537bf0f65cd9f8f7b63bbe71abcf9d0df396f58621ef3be0b2487b27 deleted: sha256:556c5fb0d91b726083a8ce42e2faaed99f11bc68d3f70e2c7bbce87e7e0b3e10 Total reclaimed space: 253.4MBナレッジ
docker-commposeのバージョン
Docker Swarmを使用する場合に、docker-commposeで使用できるバージョンは3になります。
docker-commposeでビルドする場合の留意事項
docker-commposeでビルド（stack）する場合、イメージが必要になります。
Compose file version 3 referenceより
注：（ バージョン3）Composeファイルを使用してSwarmモードでスタックをデプロイする場合、このオプションは無視され ます。このdocker stackコマンドは、ビルド済みのイメージのみを受け入れます。
そのため、Docker registryの環境が必要になります。
ローカルでDockerレジストリをセットアップする方法については、公式の以下URLが参考になります。
例として、以下の様にビルドを指定してデプロイを実行した場合、
version: '3' services: app: build: ./src以下のエラーメッセージが出力されて、デプロイをすることはできません。
failed to create service stackdemo_backend: Error response from daemon: rpc error: code = InvalidArgument desc = ContainerSpec: image reference must be providedデプロイ時のエラー
例として2台構成のホストで、docker-commpose.ymlファイルのreplicasの値を2にしてデプロイした場合は、基本的に1ホストに対して1コンテナで分散されます。
もし、デプロイ時に片方のホストで2台のコンテナが起動した場合は、何らかのエラーが発生し、片方のホストでコンテナが起動できなかったことが考えられます。エラーはLinuxの場合、シスログから確認することができます。
おわりに
不確実性があり変化の速さが求めれられる現代のアプリケーション開発には、オーケストレーションツールは必須な技術です。
応用としてサーバレスの技術を使用し、CPUやメモリリソース等のしきい値等を設定して、しきい値を超えたらサーバをスケールアウトなどの運用も行うことができます。
参考
- 投稿日：2020-02-12T05:22:31+09:00
apt --fix-brokenが発生した！！
久しぶりにVirtualboxでkali linuxをいじくり回してたらハマったので備忘録として記す。
発生原因
apt update
apt upgrade
apt dist-upgrade
彼奴らを実行後、ディスク不足で失敗
後からわかったが、不要パッケージが悪さを働き、その後の全てのaptの失敗してたっぽいエラーメッセージ内容から抜粋
apt --fix-broken install
これを実行してくれとのメッセージが出力される倣って実行するもまたエラー
/var/cache/apt/archives/*内でエラーが発生とのこと訳がわからなくなったので、aptについて学習
aptは/var/cache/apt/archives/配下にパッケージを保存していくとのこと
なので、一斉に削除することを覚悟不要パッケージは以下のコマンドで削除可能
command description sudo apt clean APTキャッシュの削除 sudo apt autoclean APTキャッシュから使っていないファイルを削除 結果
その後、アーカイブ配下は空になり、無事apt実行できるようになりました！
備考（リポジトリ確認手順）
リポジトリ参照先の編集
vim /etc/apt/sources.list貼り付け
deb http://http.kali.org/kali kali-rolling main contrib non-free参考サイト
https://blog.treedown.net/entry/2019/05/15/010000
https://news.mynavi.jp/article/20190724-864746/
- 投稿日：2020-02-12T02:46:08+09:00
AWS CLI v2 が GA(General Availability) になったので早速使ってみました。
みんな大好き AWS CLI の v2 が 2020年2月11日日本時間早朝に GA(General Availability) となりました！
わーい。
https://aws.amazon.com/jp/blogs/developer/aws-cli-v2-is-now-generally-available/筆者はAWS CLI の薄い本を書くくらい AWS CLI が好きだったりします。
というわけで、早速使ってみました。インストール
公式ガイドには Linux、 macOS、 Windows 向けのインストール手順が載っています。
今回は、 AmazonLinux2 で試したので、 Linux の手順に則ってみました。公式ガイド：https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html
インストールする
公式ガイドには以下の記載があります。
https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-linux.html#cliv2-linux-installcurl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" unzip awscliv2.zip sudo ./aws/install実際に試すとこんな感じ。
ec2-user@test ~]$ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 30.6M 100 30.6M 0 0 64.1M 0 --:--:-- --:--:-- --:--:-- 64.0M [ec2-user@test ~]$ ls awscliv2.zip [ec2-user@test ~]$ [ec2-user@test ~]$ unzip awscliv2.zip Archive: awscliv2.zip creating: aws/ creating: aws/dist/ (中略) inflating: aws/dist/zlib/cpython-37m-x86_64-linux-gnu/soib.cpython-37m-x86_64-linux-gnu.so [ec2-user@test ~]$ [ec2-user@test ~]$ sudo ./aws/install You can now run: /usr/local/bin/aws --version [ec2-user@test ~]$ [ec2-user@test ~]$ /usr/local/bin/aws --version aws-cli/2.0.0 Python/3.7.3 Linux/4.14.154-128.181.amzn2.x86_64 botocore/2.0.0dev4 [ec2-user@test ~]$早速試してみます。
本稿執筆時点での新機能は以下の通りです。
- インストーラ
- これは上記で試し済み。今までの差異としては、ビルド済みパッケージでの提供かつ前提を満たすバージョンの Python を事前にインストールする必要がなくなりました。
- 設定手順
- これまで AWS CLI に IAM ユーザーの認証情報を設定するのには、IAM ユーザー作成時に表示される情報もしくは作成時にダウンロードできる csv ファイルを参照して設定を行っていました。 v2 ではその csv ファイルをインポートして設定が可能になりました。
- また、認証方法として SSO も利用可能になりました。
- リソース名の自動補完
- すでに AWS アカウント上に存在するリソース名を補完して CLI のパラメータにしてができるようになりました。地味にすごい。
- 自動プロンプト
- 必要なパラメータ指定をアシストしてくれるようになりました。これで必須パラメータ漏れで怒られることも減ります。
- ウィザード
- いわゆる、対話型のコマンドとして動作するモードです。本稿執筆時点では一部のサービスのみに対応しています。
- yaml での出力
- 実行結果の出力形式に yaml が追加されました。
本稿では、リソース名の自動補完と自動プロンプト、ウィザード、yaml での出力について試してみます。
SSO は可能なら試行後に更新します。リソース名の自動補完
現時点では全部のサービスには対応しきっていないようです。
例えば、試行した中では Amazon EC2 や Amazon S3 のバケット名、 RDS などは対応していないようです。
今後この辺りの拡充が期待されます。というわけで、後述のウィザードに対応しているサービス(Amazon DynamoDB や AWS IAM、AWS Lambda)は対応しているようだったので、試してみました。
[ec2-user@test ~]$ aws dynamodb describe-table --table-name <TABキーを押す> 12234 table-us-east-1 [ec2-user@test ~]$ [ec2-user@test ~]$ aws iam get-user --user-name <TABキーを押す> cli codecommit hirosys [ec2-user@test ~]$ [ec2-user@test ~]$ aws lambda get-function --function-name <TABキーを押す> AWS-DeepRacer-Test-Reward-Function aws-deepracer-reward-fn-********-****-****-****-************自動プロンプト
自動プロンプト機能を使って、 Amazon VPC を作成してみました。
[ec2-user@test ~]$ aws ec2 create-vpc --cli-auto-prompt --cidr-block: 10.20.0.0/16必須パラメータである --cidr-block の指定の後、任意パラメータのリストが表示されました。
特に指定せずに一番下にある ** [DONE] Parameter input finished** を選択してEnterキーを押下すると、VPC が作成できました。
{ "Vpc": { "CidrBlock": "10.20.0.0/16", "DhcpOptionsId": "dopt-********", "State": "pending", "VpcId": "vpc-*****************", "OwnerId": "************", "InstanceTenancy": "default", "Ipv6CidrBlockAssociationSet": [], "CidrBlockAssociationSet": [ { "AssociationId": "vpc-cidr-assoc-*****************", "CidrBlock": "10.20.0.0/16", "CidrBlockState": { "State": "associated" } } ], "IsDefault": false, "Tags": [] } }無事に作成できました。
気になった点・・・
aws ec2 describe-instances を自動プロンプトモードで実行した際、 --instance-ids にインスタンスIDを指定しても、以下のメッセージが表示されて実行できませんでした。
An error occurred (InvalidInstanceID.Malformed) when calling the DescribeInstances operation: Invalid id: "-"しかし、 Print CLI command. で出力した CLI を実行する分には意図した通りに動く不思議。。。
ウィザード
[ec2-user@test ~]$ aws lambda wizard new-functionまずは作成する Lambda 関数の名前を指定します。
次に、使用するランタイムの種類やバージョンをリストから選択します。
さらに、どのロールを使用するかをリストで選択します。
そして、 handler と Lambda 関数が入った zip ファイルを指定して、
最終的には以下のような感じになり、実行します。[ec2-user@test ~]$ aws lambda wizard new-function Enter the function name: cliv2 Select the Lambda runtime Select the role to use Enter the handler for your function: lambda_function.lambda_handler Enter the new location of your code zip file: cliv2_test.zip [ec2-user@test ~]$特にエラーなく実行できれば Lambda 関数の作成に成功しています。
以下は、マネージメントコンソールで確認した結果です。
リストから選択したランタイムやロールが表示されると尚良さそうですね。
yaml での出力
好みの問題もあるかもしれませんが、個人的には yaml は読みやすいと思っているのでこのアップデートはナイスです。
[ec2-user@test ~]$ aws ec2 describe-instances --output yaml Reservations: - Groups: [] Instances: - AmiLaunchIndex: 0 Architecture: x86_64 BlockDeviceMappings: - DeviceName: /dev/xvda Ebs: AttachTime: '2020-02-11T14:25:47+00:00' DeleteOnTermination: true Status: attached VolumeId: vol-***************** CapacityReservationSpecification: CapacityReservationPreference: open ClientToken: '' CpuOptions: CoreCount: 1 ThreadsPerCore: 1 EbsOptimized: false EnaSupport: true HibernationOptions: Configured: false Hypervisor: xen IamInstanceProfile: Arn: arn:aws:iam::************:instance-profile/role-tsuyoi Id: ********************* ImageId: ami-***************** InstanceId: i-***************** InstanceType: t2.micro KeyName: *********** LaunchTime: '2020-02-11T14:25:46+00:00' MetadataOptions: HttpEndpoint: enabled HttpPutResponseHopLimit: 1 HttpTokens: optional State: applied Monitoring: State: disabled NetworkInterfaces: - Association: IpOwnerId: amazon PublicDnsName: ec2-***-***-***-***.ap-northeast-1.compute.amazonaws.com PublicIp: ***.***.***.*** Attachment:まとめ
AWS CLI はもともと好きでしたが、今回の v2 でさらにかゆいところに手が届く機能に変身しており、ますます好きな機能になったと感じました。
皆さんもこの機会に AWS CLI に触れてみてはいかがでしょうか。
- 投稿日：2020-02-12T01:10:31+09:00
Linux VMでVSCode + Dockerの開発環境をつくる
VSCodeのRemote(Container) プラグインが便利だったので、VM上に開発環境を構築してみた。
Windows VM上には素直にDockerをインストールできない(ゲストOS上ではHyper Vオプションが無効)。
そこで、Linux VMでリモートデスクトップを使えるようにして、開発環境を構築してみた。
1. VM準備
- Cent OS 7でVMを作成する。
（Cent OS 8で後続の手順で環境構築すると、セットアップ直後はRDPでつながるが、再起動後にVMにSSHもRDPも接続できなくなる問題が発生したのでやり直した）
2. Remote Desktopをセットアップ
- VMにSSH接続して、Rootユーザーに切り替え。
sudo su -
以下サイトを参考に、RDPのパッケージをインストールする。WindowsのRDPを使ってクラウド上のLinuxインスタンスに接続する - Qiita
RDP用ユーザーを作成。必要に応じてsudoリストに追加。
$ useradd sampleuser $ passwd sampleuser $ usermod -aG wheel sampleuser
- （お好みで）デフォルトの見た目をGNOMEクラシックからGNOMEに変更
echo 'DESKTOP="GNOME"' >> /etc/sysconfig/desktop systemctl restart gdm.service3. リモートデスクトップでVMに接続
リモートデスクトップアプリを使ってVMに接続する。
4. Visual Studio Code をインストール
- 公式サイトからrmpファイルをダウンロードしてyumでインストール
cd ~/path/to/download/ sudo yum install code-1.42.0-1580986751.el7.x86_64.rpm
- Remote(Conteiner)プラグインをインストールする VSCode上で「Remote(Conteiner)」プラグインを検索して、インストールする。
5. Dockerのインストール
- 以下のサイトを参考にDockerをインストールする
- Dockerグループにユーザーを追加する
$ usermod -aG docker sampleuser6. VS CodeでDocker実行
- 「リモートエクスプローラー」タブ内の「+」ボタンをクリック
- 「Open Folder in Container」 を選択し、ブランクフォルダーを選択
- 「Python 3」コンテナーを選択して実行
- Python 3 コードが実行できるコンテナーが起動する
