はじめに

dockerでpixelmonサーバ立ち上げたことがあったので、備忘録として残します。
いやぁ、楽しいですよねマインクラフト

あと、今回ネットワークと、サーバ設定周りは触れませんので、そこらへんはあしからず
(機会があったら家のサーバ環境とかも取り上げたいです！)

構築環境

・centos7
　うん、docker動けばどこでもいいよ
・minecraft version 1.12.2
・forge version 14.23.5.2768
（これwin側のバージョンは違うかもです)
・pixelmon version 2.4.2

自分が構築した時期も少し前と言うこともあり
全体的に古いバージョンなのですが、そこは臨機応変におねです

内容

ディレクトリ構造

centosのユーザで以下ディレクトリ作成してください。
また、mods直下にpixelmonのjarを配置してください。

pokemon
|--docker-compose.yml
|--25565
|　　|--data
|　　|--mods
|　　　　|--PixelmonGenerations-1.12.2-2.4.2-universal.jar

docker-compose

docker-compose

version: '3'
services:
    minecraft-server:
        container_name: miutipokemon　　
        image: itzg/minecraft-server
        ports:
            - "25565:25565"
        tty: true
        stdin_open: true
        restart: always
        volumes:
            - ./25565/mods:/data/mods/
            - ./25565/data:/data/
        environment:
            EULA: "TRUE"
            VERSION: "1.12.2"
            TYPE: "FORGE"
            FORGEVERSION: "14.23.5.2768"
            SPAWN_MONSTERS: "false"

(これどうやったら色つくようにできるんだろう・・・)
軽く中身を説明すると
volumesの/data/modsでjarファイルをコンテナ内に同期させ、/dataでデータを永続化してます。
なので、バックアップを取りたい場合は、ホスト側の25565/dataの中身
全部取っておけばおっけーです。

environmentの中の設定詳細は以下URL
https://hub.docker.com/r/itzg/minecraft-server

実行

docker-composeが配置されてるディレクトリにて

$ docker-compose up -d

と実行するだけ！
あとは、ネットワーク環境によりますがサーバ指定して入ってもらえば
OKです！

僕のサーバ公開しているので、遊びたいかたいたら一声かけてくださーい。

Visual Studio Codeの環境移行のやり方を紹介します．

最新のバージョンでは，環境移行がかなり簡単になっています．

使用バージョンとOS

• Visual Studio Code 1.36.1
• Ubuntu 18.04 LTS(※Windows向けの情報もうろ覚えですが，記載してます．)

環境移行に必要なフォルダ

下の2つのフォルダを，古いPCから(USBメモリ等)に退避させ，新しいPCで同じ場所に置いてあげるだけ．

• ~/.vscode( Windows : %USERPROFILE%\.vscode ) ディレクトリ
  • このディレクトリの中にプラグインのファイルが入ってたりします．
• ~/.config/Code/User( Windows : %APPDATA\Code\User ) ディレクトリ
  • このディレクトリの中に基本設定やキーコンフィグが入ってたりします．

実行時にデバッグ出力する場合のヘッダ

#!/bin/bash -x

root以外が実行すると処理せずに終了させる

if [ $(whoami) != "root" ]; then
        echo "This script must be run as root"
        exit 1
fi

スペースの入ったファイル名を処理するために配列の分割子を改行コードに固定する

export IFS=$'\n'

ので、上記設定以降はshell内での配列指定は以下の例のように記述する必要がある

EXTLIST=(
"mov"
"mkv"
"..avi"
"avi.mp4"
"wmv.mp4"
"flv.mp4"
"mpeg"
"mpg"
"flv"
"rmvb"
"wmv"
"M4A"
"avi"
"ts")

rootから全てのユーザのjavaに対してgc実行リクエストする

for line in `ps aux | grep java | tr -s " " | grep -v grep | tr " " "," | cut -d ',' -f 1-2`
do
        arr=( `echo $line | tr -s ',' ' '`)
        user=${arr[0]}
        pid=${arr[1]}
        sudo -u $user jmap -histo:live $pid
done

lockファイルを作らずに、shellの複数起動をしないようにする

参考 : https://qiita.com/hit/items/e95298f689a1ee70ae4a

_pcnt=`pgrep -fo ${CMDNAME} | wc -l`               
if [ ${_pcnt} -gt 1 ]; then                        
        echo "This script has been running now. proc : ${_pcnt}"
        exit 1                                           
fi

障害発生時の情報取得

私がこれまでにいた現場では、各ミドルウェア担当ごとに、障害情報取得スクリプトを自作していた。

問題点

• DRYできてない。
• Apacheで障害が起きたとしても、Apacheのログしか取得してない。
• 定義ファイルだけを取得するスクリプトと障害情報？を取得するものでスクリプトが別れている。もちろんメンテは片方ずつしかされてなかったりする。

こういうときって、APだったり、負荷分散だったり、のログもほしいもの。
ほしければ、自分で実装しなければいけない。

解決策

sosreportの活用を！
sosreportのプラグインを自作してしまえばいいんだ！

とりあえず定義ファイルとコマンドを抜くだけだったら以下のようにすればいい。

from sos.plugins import Plugin, RedHatPlugin

class MyPlugin(Plugin, RedHatPlugin):
    """pluginの説明"""

    def setup(self):
        self.add_copy_spec([
            "取得したいファイルのパス",
            "取得したいファイルのパス",
            "取得したいファイルのパス",

        self.add_cmd_output("実行したいコマンド")
        ])

こんなプラグインを、
/usr/lib/python2.7/site-packages/sos/plugins につっこんでおけばよい。
ファイルは普通にアーカイブされているし、コマンド結果も、
sos_commands/プラグイン名/コマンド名 で保存されている。

1. はじめに

以前に書いた以下のエントリでは、追加したブロックボリュームをLVM（論理ボリュームマネージャー）で構成した。

• OCI Computeでブロックボリュームをマウントする

LVMのメリットは多いが、クラウドや仮想サーバー環境では既存のボリュームを簡単に拡張できる（以下参照）。そこで今回はLVMを使わない方法を説明する。

既存のボリュームを拡張する方法

• オフラインにした既存のボリュームを拡張する
• ボリュームのバックアップを、より大きなサイズのボリュームにリストアする
• 既存のボリュームを、より大きなサイズのボリュームにクローンする

2. 前提条件

前回の補足的な位置づけなので、ブロックボリュームは作成＆アタッチ済みで、「5-2. ディスクパーティションを作成する」以降の差分だけを書くことにする。

3. 追加したブロックボリュームを使えるように構成する

3-1. パーティション構成を確認する

追加したブロックボリュームを確認する。すると/dev/sdbとして追加され、コンシステンス・デバイス・パス/dev/oracleoci/oraclevdbとして定義されていることがわかる。

# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sdb      8:16   0  512G  0 disk
sda      8:0    0 46.6G  0 disk
├─sda2   8:2    0    8G  0 part [SWAP]
├─sda3   8:3    0 38.4G  0 part /
└─sda1   8:1    0  200M  0 part /boot/efi

# ll /dev/oracleoci/oraclevd*
lrwxrwxrwx. 1 root root 6 Jul 16 19:13 /dev/oracleoci/oraclevda -> ../sda
lrwxrwxrwx. 1 root root 7 Jul 16 19:13 /dev/oracleoci/oraclevda1 -> ../sda1
lrwxrwxrwx. 1 root root 7 Jul 16 19:13 /dev/oracleoci/oraclevda2 -> ../sda2
lrwxrwxrwx. 1 root root 7 Jul 16 19:13 /dev/oracleoci/oraclevda3 -> ../sda3
lrwxrwxrwx. 1 root root 6 Jul 16 19:13 /dev/oracleoci/oraclevdb -> ../sdb

3-2. ディスクパーティションを作成する

LVMは使用しないので、LVMフラグを付けずに作成する。ここではコンシステンス・デバイス・パスを指定しているが/dev/sdbでもよい。

# parted -s -a optimal /dev/oracleoci/oraclevdb \
   mklabel gpt \
   mkpart primary 0% 100%

パーティション情報を確認するとsdb1が定義されていることがわかる。

# parted /dev/oracleoci/oraclevdb print
Model: ORACLE BlockVolume (scsi)
Disk /dev/sdb: 550GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End    Size   File system  Name     Flags
 1      1049kB  550GB  550GB               primary

# lsblk -o +UUID
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT UUID
sdb      8:16   0  512G  0 disk
└─sdb1   8:17   0  512G  0 part            c31941dc-9bae-4680-9c35-8f195b0db30d
sda      8:0    0 46.6G  0 disk
├─sda2   8:2    0    8G  0 part [SWAP]     d2f67c75-3f12-4abb-9c5a-ae8c23426d7c
├─sda3   8:3    0 38.4G  0 part /          666196a2-64e0-4535-a3f8-7d746a37d900
└─sda1   8:1    0  200M  0 part /boot/efi  6F4C-7CE8

3-3. 次の手順は

残るは以下の作業である。この部分は同じなので「5-6. ファイルシステムを作成する」以降を参照のこと。

• ファイルシステムの作成
• マウントポイントの作成
• /etc/fstabの作成
• ファイルシステムのマウント

1. はじめに

以前に書いた以下のエントリでは、追加したブロックボリュームをLVM（論理ボリュームマネージャー）で構成した。

• OCI Computeでブロックボリュームをマウントする

LVMのメリットは多いが、クラウドや仮想サーバー環境では既存のボリュームを簡単に拡張できる（以下参照）。そこで今回はLVMを使わない方法を説明する。

既存のボリュームを拡張する方法

• オフラインにした既存のボリュームを拡張する
• ボリュームのバックアップを、より大きなサイズのボリュームにリストアする
• 既存のボリュームを、より大きなサイズのボリュームにクローンする

2. 前提条件

前回の補足的な位置づけなので、ブロックボリュームは作成＆アタッチ済みで、「5-2. ディスクパーティションを作成する」以降の差分だけを書くことにする。

3. 追加したブロックボリュームを使えるように構成する

3-1. パーティション構成を確認する

追加したブロックボリュームを確認する。すると/dev/sdbとして追加され、コンシステンス・デバイス・パス/dev/oracleoci/oraclevdbとして定義されていることがわかる。

# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sdb      8:16   0  512G  0 disk
sda      8:0    0 46.6G  0 disk
├─sda2   8:2    0    8G  0 part [SWAP]
├─sda3   8:3    0 38.4G  0 part /
└─sda1   8:1    0  200M  0 part /boot/efi

# ll /dev/oracleoci/oraclevd*
lrwxrwxrwx. 1 root root 6 Jul 16 19:13 /dev/oracleoci/oraclevda -> ../sda
lrwxrwxrwx. 1 root root 7 Jul 16 19:13 /dev/oracleoci/oraclevda1 -> ../sda1
lrwxrwxrwx. 1 root root 7 Jul 16 19:13 /dev/oracleoci/oraclevda2 -> ../sda2
lrwxrwxrwx. 1 root root 7 Jul 16 19:13 /dev/oracleoci/oraclevda3 -> ../sda3
lrwxrwxrwx. 1 root root 6 Jul 16 19:13 /dev/oracleoci/oraclevdb -> ../sdb

3-2. ディスクパーティションを作成する

LVMは使用しないので、LVMフラグを付けずに作成する。ここではコンシステンス・デバイス・パスを指定しているが/dev/sdbでもよい。

# parted -s -a optimal /dev/oracleoci/oraclevdb \
   mklabel gpt \
   mkpart primary 0% 100%

パーティション情報を確認するとsdb1が定義されていることがわかる。

# parted /dev/oracleoci/oraclevdb print
Model: ORACLE BlockVolume (scsi)
Disk /dev/sdb: 550GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End    Size   File system  Name     Flags
 1      1049kB  550GB  550GB               primary

# lsblk -o +UUID
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT UUID
sdb      8:16   0  512G  0 disk
└─sdb1   8:17   0  512G  0 part            c31941dc-9bae-4680-9c35-8f195b0db30d
sda      8:0    0 46.6G  0 disk
├─sda2   8:2    0    8G  0 part [SWAP]     d2f67c75-3f12-4abb-9c5a-ae8c23426d7c
├─sda3   8:3    0 38.4G  0 part /          666196a2-64e0-4535-a3f8-7d746a37d900
└─sda1   8:1    0  200M  0 part /boot/efi  6F4C-7CE8

3-3. ファイルシステムを作成する

ファイルシステムをxfsでフォーマットする。ext4のときには、代わりにmkfs.ext4を指定する。

# mkfs.xfs /dev/oracleoci/oraclevdb1
meta-data=/dev/oracleoci/oraclevdb1 isize=256    agcount=4, agsize=33554304 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=0        finobt=0, sparse=0, rmapbt=0, reflink=0
data     =                       bsize=4096   blocks=134217216, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=65535, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

3-4. 次の手順は

残るは以下の作業である。この部分は同じなので「5-7. ブロックボリュームをマウントする」以降を参照のこと。

• マウントポイントの作成
• /etc/fstabの作成
• ファイルシステムのマウント

findは様々な方法でファイル検索ができる。

xargsとの併用に関しては別スレッド

$ find [directory] [検索方法] [検索正規表現]

ディレクトリは適当なものを。（現階層ならば.や./*など...）

検索正規表現に関しては、*使用時のみエラー発生することがあるので""で囲む。

#簡単なファイル名検索であればこれらでOK
$ find . -name "hoge*"
$ find ./* -name "*.rtf"
$ find /test -name "num"

大小文字区別のオプションに関してはgrepと同じくiで対処だがinameと記述する点に注意

$ find /test -iname "HoGe*"

findコマンドで得た結果の一通りの情報を得る場合は-lsを末尾に追加

$ find /test -iname "HO*" -ls

これでアクセス権限等を含めた結果が得られる

64363231536 4 -rw-r--r-- 1 sf213471118 admin 32 7 16 17:06 ./hoge.rtf

ファイル名検索以外で使いそうなものは以下

#ファイルサイズで検索( 50>=size , 50<size)
$ find ./* -size +50
$ find ./* -size -50

#最新の変更日時で検索( 60<=min , 7>days)
$ find ./* -mmin +60
$ find ./* -mtime -7

grep

grep は特定の文字列を含むファイルの検索ができる。

$ grep [検索正規表現] [option] [directory] 

[検索正規表現] [option]については順不同。

ディレクトリは、例えば現階層のファイル全てから検索であれば./*で検索。

オプションは主に使うものだけ以下にメモ

#大文字と小文字を区別せず検索
$ grep [検索正規表現] -i [directory] 

#一致しないものを検索
$ grep [検索正規表現] -v [directory] 

#行番号と併せて表示
$ grep [検索正規表現] -n [directory] 

#ファイル名のみ表示
$ grep [検索正規表現] -l [directory] 

#ディレクトリ内も検索に含める
$ grep [検索正規表現] -r [directory] 

grep

grep は特定の文字列を含むファイルの検索ができる。

xargsとの併用に関しては別スレッド。

$ grep [検索正規表現] [option] [directory] 

[検索正規表現] [option]については順不同。

ディレクトリは、例えば現階層のファイル全てから検索であれば./*で検索。

オプションは主に使うものだけ以下にメモ

#大文字と小文字を区別せず検索
$ grep [検索正規表現] -i [directory] 

#一致しないものを検索
$ grep [検索正規表現] -v [directory] 

#行番号と併せて表示
$ grep [検索正規表現] -n [directory] 

#ファイル名のみ表示
$ grep [検索正規表現] -l [directory] 

#ディレクトリ内も検索に含める
$ grep [検索正規表現] -r [directory] 

日本語の情報があまり見つからなかったので記載してみました。
以下のようなニッチなユースケースくらいしかないと思いますので、ほぼ自分用の備忘録になるかと。。。

• ディスプレイが部分的に壊れてEDIDが取得できない
• 強制的に任意の解像度を指定したい
• 仕事で開発中の評価ボード等で何か問題があって、ダミーのEDIDを読ませたい

ただし、Kernel v5.1.5 以前の環境では脆弱性が指摘されている（CVE-2019-12382）ので、
対策されていない環境での利用は推奨しません。

なお、2019/6/27 時点で Upstream Kernel (Linus のTree) の master ブランチには
対策パッチが入っていませんでしたが、
DRM Subsystem の drm-next ブランチには対策パッチが入っていましたので、
じきにマージされるはずですし、シンプルな修正の為、容易に Cherry-pick できると思います。

確認環境

• Linux Kernel v4.14.75 ltsi

手順

1. menuconfig で CONFIG_DRM_LOAD_EDID_FIRMWARE を有効化してKernel Imageをビルドする

(ビルド手順はこちら)

$ make menuconfig

Symbol: DRM_LOAD_EDID_FIRMWARE [=y]
Type  : boolean
Prompt: Allow to specify an EDID data set instead of probing for it
　
Location:
   -> Device Drivers
      -> Graphics support
         -> Allow to specify an EDID data set instead of probing for it

2. Linux Kernel に読み込ませる EDID のバイナリを作成する

CONFIG_DRM_LOAD_EDID_FIRMWARE が有効になると、以下の解像度については
Kernel Image に bulit-in で組み込まれるため、それ以外の解像度を指定したいときに
自分で EDID のバイナリを指定することになります。

• 800x600
• 1024x768
• 1280x1024
• 1600x1200
• 1680x1050
• 1920x1080

作り方については Documentation/EDID/HOWTO.txt もご参照ください。

$ cd ${WORK}/${KERNEL_TREE}/Documentation/EDID/
$ cp 1024x768.S WIDTHxHEIGHT.S
$ vi WIDTHxHEIGHT.S
$ make

作成したバイナリの中身については以下のコマンドで確認できます。

$ edid-decode WIDTHxHEIGHT.bin

例　(クリックすると展開されます)

$ edid-decode 1920x1080.bin
1罹2x袰$YJ% PT兩:q8-@X,E・inux #0
    ・=BD
      鑅inux FHD
   Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   31 d8 00 00 00 00 00 00 05 16
version:         01 03
basic params:    6d 32 1c 78 ea
chroma info:     5e c0 a4 59 4a 98 25 20 50 54
established:     00 00 00
standard:        d1 c0 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1:    02 3a 80 18 71 38 2d 40 58 2c 45 00 f4 19 11 00 00 1e
descriptor 2:    00 00 00 ff 00 4c 69 6e 75 78 20 23 30 0a 20 20 20 20
descriptor 3:    00 00 00 fd 00 3b 3d 42 44 0f 00 0a 20 20 20 20 20 20
descriptor 4:    00 00 00 fc 00 4c 69 6e 75 78 20 46 48 44 0a 20 20 20
extensions:      00
checksum:        05

Manufacturer: LNX Model 0 Serial Number 0
Made week 5 of 2012
EDID version: 1.3
Analog display, Input voltage level: 0.7/0.7 V
Sync: Separate Composite Serration
Maximum image size: 50 cm x 28 cm
Gamma: 2.20
DPMS levels: Standby Suspend Off
RGB color display
First detailed timing is preferred timing
Established timings supported:
Standard timings supported:
  1920x1080@60Hz
Detailed mode: Clock 148.500 MHz, 500 mm x 281 mm
               1920 2008 2052 2200 hborder 0
               1080 1084 1089 1125 vborder 0
               +hsync +vsync
Serial number: Linux
Monitor ranges (GTF): 59-61Hz V, 66-68kHz H, max dotclock 150MHz
Monitor name: Linux
Checksum: 0x5 (valid)
EDID block does NOT conform to EDID 1.3!
        Detailed block string not properly terminated

　

また、PC や 評価ボード側に問題があって EDID が取得できない場合には
別の PC とディスプレイを取得して、 PC がディスプレイから取得した EDID を
そのままバイナリ化しても良いと思います。

$ find /sys/devices/ -name edid
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1/card1-HDMI-A-2/edid
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1/card1-DVI-D-1/edid
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1/card1-DVI-I-1/edid
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1/card1-DP-1/edid
/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-1/edid
/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-VGA-1/edid
$ cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1/card1-DP-1/edid > DISPLAY.bin

3. 作成したバイナリを Rootfs にコピーする

$ sudo cp WIDTHxHEIGHT.bin ${ROOTFS}/lib/firmaware/edid/WIDTHxHEIGHT.bin

4. Kernel の bootargs に "drm_kms_helper.edid_firmware" を追加する

例：

drm_kms_helper.edid_firmware=edid/WIDTHxHEIGHT.bin

前述していますが、以下の指定をした場合には EDID が built-in されていますので、
Rootfs にバイナリが無くても動作します。

• drm_kms_helper.edid_firmware=800x600.bin
• drm_kms_helper.edid_firmware=1024x768.bin
• drm_kms_helper.edid_firmware=1280x1024.bin
• drm_kms_helper.edid_firmware=1600x1200.bin
• drm_kms_helper.edid_firmware=1680x1050.bin
• drm_kms_helper.edid_firmware=1920x1080.bin

built-in されるバイナリについては "drivers/gpu/drm/drm_edid_load.c" 内の
"static const char * const generic_edid_name[]" で列挙されています。

制限事項 ?

シングルディスプレイの場合には問題ありませんが、
マルチディスプレイ環境で "drm_kms_helper.edid_firmware" を指定してしまうと
全てのディスプレイが指定した EDID を使用してしまうようで、
１つのディスプレイだけ設定したい、ということが出来ないようです。
（仕様なのか私の環境固有の問題なのかは未調査です）

TL;DR

Ctrl + Alt + Pでもとに戻る

fcitx + mozcで入力中の文字が表示されない

LinuxでのIMEはFcitx + mozcがメジャーかなと思いますが、度々「入力中の文字がプレビューされない」という問題に直面します。

この問題が発生してる人はやっぱりそこそこいるみたいで、調べると「Fcitx XIM Frontendのチェックを外したりつけたりする」とか「~/.confg/fcitxを削除して再起動」とか、「fcitxを消して再インストール」とかがヒットします。

確かにこれで治ることもあるのですが、治らないこともありなんだかよくわからないうちに治ってたりといまいち原因がわからず毎回トラブルシューティングに時間をかけてしまっていました。

原因

fcitxに「入力中の文字表示をオンオフするショートカット」がありました...
デフォルトでCtrl + Alt + Pに振られており、何かの拍子に押してしまってこの状態になっていたようです。

設定の削除だとか再インストールだとかで治ったケースはこのオンオフ状態が初期状態に戻っているから治っていたようで、逆にその状態が維持されたままだと何しても解決しません。

うっかり発動しても困るので、このショートカットを無効化しておきましょう。

Fcitxの設定からGlobal Configタブを選択し、「Show Advance option」にチェックを入れると詳細設定画面になります。
Hotkeyタブに「Switch Embedded Preedit」という項目があるので、ここのショートカットを空にしてOKを押せば二度とこの現象は発生しなくなります。

これを削除してEmptyにする

以上で完了です。

おわりに

この機能いる...？

■Linuxホスト名変更
https://qiita.com/myabiot/items/4583baa472bd4a630c3c

■ntpサーバ(CentOS)と自動同期しない場合の設定
https://qiita.com/myabiot/items/273feef3912666c709d3

■CentOS6.7 virtualBOXでクローンを作成したOSがネットワークへ抜けない場合
https://qiita.com/myabiot/items/4aa8a87adae943469f33

• 日々輩出される素晴らしき最新サービスを素早く試して、不鮮明な先見性を堂々と誇示する記事第八弾。
• 歴史的偉人の集中力の記事の、収集作業に精を出している生活。
• 今回は、curlでの出力の際に、Terminal上であらゆる高機能な作業が可能な「curlx」を試用することにしよう。

概要

• レスポンス確認やAPI通信の際の際に用いる「curl」のリクエストの管理が捗るコマンドツール。
• 「JSONでの出力結果の整形」や「リクエストのコレクション(グループ化)」等の機能を、GUIツール等を利用せずに、ターミナル内のみで可能。
• GUIツールの「Postman」やJSON整形コマンドツールの「jq」の両方の機能を備えたようなツール。
• 公式サイト
• 公式Github

特徴

出力結果の整形

• 可読が容易ではないcurlでのJSON出力結果を、cxでは整形して、見やすく表示してくれる。
• jqを利用することなく、標準で整形してくれる。

リクエスト履歴の視覚化

• リクエスト履歴の確認が容易に可能であることに加え、ステータスや通信形式、時間等の詳細情報が表として、わかりやすく確認できる。

リクエストのコレクション(グループ)化

• リクエストをカテゴリごとにグループ化できるため、「よく投げるコマンドのエイリアス登録」や「内容別でのリクエストのグループ管理」が可能。
• Postmanでのコレクション機能を、ターミナル内で利用が可能。

結果

• ※テストAPIとして、LivedoorさんのWeather Hackを利用。

• 下記のように、curlでは見づらいjson形式や文字化けが、簡単なコマンドで見やすくなる。

• 通信形式やステータス結果等も含んだ、わかりやすい履歴の表示も可能。

• よく使う出力等を、グループ化で整理して、簡単なコマンドでリクエストが可能。

作業環境

• Amazon Linux 2
• Node.js v10.16.0
• npm 6.9.0
• ※Node.js環境が利用できれば、MacやWindowsでも可能。

インストール

• curlxのインストールは、Nodejsのnpmやyarnで可能なため、未導入の場合は、下記を参考にインストールする。

  • MacでのNode.jsインストール
  • WindowsでのNode.jsインストール
  • LinuxでのNode.jsインストール
  • Amazon LinuxでNode.jsインストール

• Node.jsのインストール後、下記のコマンドをうち、バージョン確認をする。

# Node.jsのバージョン確認
$ node -v

# npmのバージョン確認
$ npm -v

• 確認後、下記のコマンドをうち、「curlx」のインストールを行う。

# curlxのインストール
$ sudo npm install curlx -g

# バージョン確認
$ cx version

基本操作

• curlxの基本操作は、下記。
  • ※基本的にcurlコマンドをcxに置き換えるだけで可能。

内容	コマンド
通常リクエスト	cx 接続先URL ※オプション指定なしで、ヘッダー出力やjson整形が可能。
リクエスト(オプション付き)	cx -オプション URL ※オプションは、curlと同様なため、curlをcxに置き換えるだけ。 例 : cx -X GET URL
リクエスト履歴確認	cx history
リクエストのグループ(コレクション)化	cx new collections 実行後、いくつかの質問に回答していく形で、作成していく 詳細は、下記の操作例を確認。
作成コレクションへのリクエストの追加	cx new request コレクション作成同様、質問形式で追加していく 詳細は、下記の操作例を確認。
コレクション一覧	cx collections
idやコレクションリクエストでの実行	cx run <id or collection_id> 詳細は、下記の操作例を確認。
リクエストやコレクションの削除	cx delete <id or collectionname> 詳細は、下記の操作例を確認。
ヘルプページ確認	cx help
バージョン確認	cx version

操作例

通常リクエスト

• 下記のコマンドをうち、URLでの通常リクエストを行う。
  • ※オプションは、curlと同様に扱えるため、cxに置き換えるだけでよい。

# 通常リクエスト
$ cx http://weather.livedoor.com/forecast/webservice/json/v1?city=471010

# オプション指定でのリクエスト
$ cx -X GET http://weather.livedoor.com/forecast/webservice/json/v1?city=471010

コレクションの作成〜実行

• 下記のコマンドをうち、cxコマンドをグループ化することで、任意の名前とidでリクエストが可能。

# コレクション(グループ)を作成
$ cx new collection

✔ Name of your new collection … コレクション名(例:getWeather)入力

This collection already exists
✔ Would you like to add a new request to getWeather … リクエスト追加確認(例:yes)

✔ Enter complete request  eg: cx -X GET https://httpbin.org/get … 実行コマンド入力(例:cx -X GET URL)

✔ Give a name for your request … リクエスト名(例:getOkinawa)

# コレクション一覧確認
$ cx collections

┌────────────┬────────────────────┬────────┬──────────────────────────────┐
│ id         │ name               │ method │ url                          │
├────────────┼────────────────────┼────────┼──────────────────────────────┤
│ y2Q9JCOjL  │ getOkinawa         │ get    │ http://weather.livedoor.com… │
└────────────┴────────────────────┴────────┴──────────────────────────────┘


# id名でのリクエスト実行
# まず、history(履歴)内のid名での実行
$ cx history

┌────────────┬────────┬──────────────────────────────┬────────┬────────────┐
│ id         │ method │ url                          │ status │ timestamp  │
├────────────┼────────┼──────────────────────────────┼────────┼────────────┤
│ H0yIigcQv  │ get    │ http://weather.livedoor.com… │ 200    │ 2019-7-13  │
│            │        │                              │        │ 12:51 PM   │
├────────────┼────────┼──────────────────────────────┼────────┼────────────┤

$ cx run H0yIigcQv

{
  "pinpointLocations": [
    {
      "link": "http://weather.livedoor.com/area/forecast/4720100",
      "name": "那覇市"
    },
    {


# コレクション内のリクエストidでの実行
# ※コレクション内のidは、コレクション名も同時に明記する必要がある。
$ cx run getWeather y2Q9JCOjL

{
  "pinpointLocations": [
    {
      "link": "http://weather.livedoor.com/area/forecast/4720100",
      "name": "那覇市"
    },

コレクションへのリクエスト追加

• 下記のコマンドをうち、既存コレクションに新規リクエストを追加

# コレクション確認
$ cx collections

┌────────────┬────────────────────┬────────┬──────────────────────────────┐
│ id         │ name               │ method │ url                          │
├────────────┼────────────────────┼────────┼──────────────────────────────┤
│ y2Q9JCOjL  │ getOkinawa         │ get    │ http://weather.livedoor.com… │
└────────────┴────────────────────┴────────┴──────────────────────────────┘

# リクエストの新規追加
$ cx new request

✔ Name of your new collection … コレクション名(getWeather)入力

✔ Enter complete request  eg: cx -X GET https://httpbin.org/get … 実行コマンド(例:cx URL)

✔ Give a name for your request … リクエスト名(getOsaka)

# コレクション一覧再確認
$ cx collections

┌────────────┬────────────────────┬────────┬──────────────────────────────┐
│ id         │ name               │ method │ url                          │
├────────────┼────────────────────┼────────┼──────────────────────────────┤
│ y2Q9JCOjL  │ getOkinawa         │ get    │ http://weather.livedoor.com… │
├────────────┼────────────────────┼────────┼──────────────────────────────┤
│ nG3nzD53k  │ getOsaka           │ get    │ http://weather.livedoor.com… │
└────────────┴────────────────────┴────────┴──────────────────────────────┘

リクエストidやコレクションidの削除

• 下記のコマンドをうち、リクエストidやコレクションの削除を行う。

# id名でのリクエスト削除
$ cx delete H0yIigcQv

# コレクション内のid名でのリクエスト削除
$ cx delete getWeather:y2Q9JCOjL

操作履歴やコレクション確認

• curlxの操作履歴やコレクション一覧は、下記のファイルで確認できる。
  • ※curlxの履歴やコレクションといった情報は、ルートフォルダの「cxdb」というフォルダに保存されている。
  • ※簡単な履歴やコレクション確認の際は、上記の操作例での操作方法で可能。

# 操作履歴格納ファイルの中身確認
$ less ~/cxdb/history.json

{
  "history": [
    {
      "id": "UsVI7Oq9Y",
      "method": "get",
      "command": "curl -i \"http://weather.livedoor.com/forecast/webservice/json/v1?city=471010\"",
      "url": "http://weather.livedoor.com/forecast/webservice/json/v1?city=471010",
      "status": "200",
      "ts": "2019-7-12 11:58 PM"
    },
    {
      "id": "So_ybzFn3",
      "method": "get",
      "command": "curl -i \"http://weather.livedoor.com/forecast/webservice/json/v1?city=471010\"",
      "url": "http://weather.livedoor.com/forecast/webservice/json/v1?city=471010",
      "status": "200",
      "ts": "2019-7-13 12:01 AM"
    },

# コレクション一覧ファイルの中身確認
$ less ~/cxdb/collection.json

{
  "collections": {
    "getWeather": [
      {
        "id": "y2Q9JCOjL",
        "name": "getWeather",
        "method": "get",
        "command": "curl -i \"-X\" \"GET\" \"http://weather.livedoor.com/forecast/webservice/json/v1?city=471010\"",
        "url": "http://weather.livedoor.com/forecast/webservice/json/v1?city=471010"
      }

まとめ

• 今回は、curlでのAPI結果整形ということで、「Terminalのみでの利用幅の拡大」による「パソコンの容量削減」を感慨深く染みながら、記事を書く。
• 「利用機能による、GUIツールとCUIツールの併用」の誓いは、すぐさま「日毎の気分利用」に変化することを確信。
• しばらく、この賢人ツールとの付き合いが続くと感じたため、より一層開発者礼拝を強化。

参考

• https://curlx.dev/
  →公式サイトです。大変お世話になりました。
• https://github.com/shivkanthb/curlx
  →公式Githubです。大変お世話になりました。
• https://entry.anypicks.jp/product-curlx/
  →こちらの記事で知りました。大変お世話になりました。