まだプログラマーですが何か?

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

2019/04

この記事の続きです:
"Play with Docker" で遊ぶ(1)

前回は Play with Docker(以下 "PwD")というサービスを使うことで Docker をインストールすることなく、ブラウザだけで docker コマンドを体験できることを紹介しました。今回はこのサービスの標準機能として提供されている Docker Swarm を使ったクラスタリング環境構築の手順を確認してみます。

Docker Swarm は Docker に対応したネイティブ&軽量なクラスタリング用のツールです。Docker の標準機能の一部として提供されているので、Kubernetes のように Docker 導入の後から追加でインストールする必要なく(Swarm モードに切り替えるだけで)利用できます。

では早速 PwD で Docker Swarm を使ってみましょう。まずは前回同様、Docker Hub のアカウントで PwD にログインします:
2019041901


PwD のダッシュボード画面が表示されます。まずは前回同様に "+ ADD NEW INSTANCE" をクリックして Docker インスタンスを追加します:
2019042101


"node1" という名称の Docker ノードインスタンスが追加され、操作するためのコンソールも表示されました。ここまでは前回と同じです:
2019042102


今回はクラスタリング環境を構築したいので、更に2つの Docker ノードインスタンスを追加します(合計3つにします)。あともう2回 "+ ADD NEW INSTANCE" をクリックして、"node2" と "node3" を追加します。こんな感じで Docker ノードを気軽に増やせるのは本当に便利です。。
2019042103


この時点で3つの Docker が(独立した状態で)準備できました。ではこの3つの Docker ノードを使ってクラスタリング環境を構築します。今回は node1 を管理ノード、node2 と node3 をワーカーノードとするクラスタリング環境とします。

まずは管理ノードを準備します。node1 を選択して、node1 のコンソールに以下のコマンドを入力します:
$ docker swarm init --advertise-addr eth0

2019042104


成功すると出力結果に
$ docker swarm join --token XXXXXX...
という内容が表示されます。これはワーカーノードとなるノードで入力すべきコマンドです。これで管理ノードの準備はできました。


では次にワーカーノードをこの管理ノードに接続します。先程の管理ノードでのコマンド出力結果の "docker swarm join --token XXXXXX..." 部分をそのまま node2 のコンソールにコピー&ペーストして実行します:
2019042105


"This node joined a swarm as a worker." というメッセージが表示されれば正しくワーカーノードとしてクラスタリングに追加し、初期化できたことになります。

同様に node3 でも同じコマンドを実行して、ワーカーノードとしてクラスタリングに追加します:
2019042106


これで3つの Docker インスタンスノードによるクラスタリング環境が構築できているはずです。念の為、node1 ノードで以下のコマンドを実行します:
$ docker node ls

実行結果を見ると、node1, node2, node3 の3つのノードがクラスタリングを構成している様子が表示され、かつ node1 が "Leader" (管理ノード)と表示されているはずです:2019042107



では、このクラスタリング環境でアプリケーションを実行してみます。なお原則的には以下のコマンドはすべて管理ノードである node1 ノードのコンソールを使います。

改めて node1 ノードで nginx のイメージを使って 80 番ポートで、1インスタンスで、"web" という名前でサービスを作成します:
$ docker service create --replicas 1 --name web -p 80:80 nginx

初回はイメージのダウンロードもあるので少し時間がかかりますが、以下のようなメッセージが表示され、正しくサービスが作成されます:
2019042108


動作確認する前に、この時点でサービスの様子を確認します。node1 ノードで以下のコマンドを実行します:
$ docker service ls

"web" というサービスがレプリカ1つで定義され、そのうちの1つが動いている形で 80 番ポートで作成されている様子が確認できます:
2019042109


実際に動作確認してみます。80 番ポートで公開されているので、curl コマンドを使って以下のコマンドを実行します(このコマンドは node2 や node3 で実行しても確認できます):
$ curl http://localhost/

Nginx 標準のトップページの HTML が表示されます。正しくサービスが動いている様子が確認できました:
2019042110


では、現在1インスタンスで稼働しているこのサービスを複数インスタンスとなるように node1 でスケールアウトさせてみます:
$ docker service scale web=3

3インスタンスで稼働するように指定しました。少し待ちますが、3つのインスタンスが "running" となることを確認します:
2019042101


改めてnode1 でレプリカ数を確認します:
$ docker service ls

結果、以下のように3つのレプリカが定義されており、そのうちの3つが動いている様子が確認できます:
2019042102


最後に作成したサービス(web)を削除する方法を紹介しておきます。node1 で以下のコマンドを実行します:
$ docker service rm web

これで web サービスはクラスタリング環境から削除されました:
2019042103



PwD 環境を使ったクラスタリング環境構築と、簡単なサービス作成&スケールアウト&削除といった手順を紹介しました。 通常、同じことを行うには3台のマシンを用意した上で、それぞれに Docker をインストールしておかないとこのような動作確認はできないのですが、PwD を使うと Docker 導入の手順を省略することができる上、全ての操作を1つのブラウザ画面上で行うことができるという点が勉強しやすいと感じました。




"Play with Docker" (以下、"PwD")というサービスを使ってみました:
https://labs.play-with-docker.com/


2019041901


一言でいうと「ブラウザだけで docker コマンドを体験できるサービス」です。普通、Docker を使うには(当然ですが)Docker 環境が必要です。自分でインストールすることもできますし、各種クラウドサービスで提供されているものを使ってもいいです。自分でインストールせずにクラウドサービスの Docker サービスを利用する場合は別途手元のマシンに docker クライアントを導入&セットアップして使うことになります。一度セットアップしてしまえばいい話ではありますが、慣れてなかったり「そもそも Docker って何?」という人がこれから勉強するために用意することを考えると「ちと面倒」です。

この PwD は、そんな Docker のセットアップ手順をすっ飛ばして Docker を使うことができるサービスです。具体的には Docker Hub のアカウントを取得し、そのアカウントでログインするとブラウザ上で docker 他の各種コマンドが使えるターミナルが提供され、裏で動いている Docker エンジンや、オーケストレーション環境である Docker Swarm エンジンを利用することができる、というものです。

利用するにはブラウザで PwD サイトへアクセスし、"Login" と書かれたボタンをクリックして Docker Hub のアカウントでログインします(所有していない場合はここで作成してログイン):
2019041901


ログイン後に改めて同ページを参照し、今度は "Start" ボタンをクリックしてサービス開始です:
2019041902


PwD サービス画面に切り替わります。画面左上にこのセッションで使える残り時間が表示されています。カウントダウンも始まっていますが、約4時間使える、ということみたいです。この時点ではまだdocker インスタンスが1つも起動していません。まずは1つ使ってみましょう。"+ ADD NEW INSTANCE" と書かれた箇所をクリックします:
2019041903


"node1" という名称のインスタンスが追加されました。同時に画面右にコンソールが現れて、プロンプト状態になります。すでに docker エンジンは起動している状態になっていて、ここから docker コマンドなどを実行することができる状態になってます。簡単すぎる・・・:
2019041904


試しに "$ docker version" を実行してみました。サーバー側もちゃんと動いてそうです:
2019041905


では深く考えずに nginx のイメージからコンテナを1つ起動してみます:
$ docker pull nginx

$ docker run -d -p 80:80 nginx


そして起動中であろう nginx にアクセスしてみます:
$ curl http://localhost/

<!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>

  :

</html>

普通に使えてますね、これはすごい!

ほぼ準備することなく Docker コマンドが使えて、コンテナの実行もできて、勉強目的であればとてもいい環境だと思いました。

次回はこの PwD で(使えることになっている)オーケストレーション環境である Docker Swarm を使ってみる予定です。




2019年4月1日午前11時40分ごろ、新しい元号の発表がありました:
gengou_happyou_reiwa_kakageru


30年ちょっと続いた「平成」は4月30日の「退位の日」を持って終わり、5月からは「令和」となります。自分自身は昭和から平成と変わる時も物心がついていたのですが、昭和天皇崩御の直後だったこともあってお祝いというよりは静粛な雰囲気で行われた記憶があります。改元自体はおめでたいことだと思うので、本来はこうあるべきなんじゃないかな、、と思っています。

さて、この新元号発表の瞬間、僕は Abema TV にへばりついて生中継を見ていました。一刻も早く新元号を知りたかった理由、それは「新元号のドメインをとりたかった」に他なりません(笑)。

ドメインというのはインターネットのネームスペースのドメインのことです。メールアドレス xxx@abc.co.jp でいう "abc.co.jp" の部分です。ドメインは原則早いもの勝ちで取得ができるもので、おそらく同じことを考えていた人は少なくないと思います。そんな中で新しい元号が発表されたら、その元号にちなんだドメイン ○○○.jp を後で高く転売してやろうとか考えて取りたかったのでした。

ちなみに、自分はいくつかのドメインを所有しています。ドメインの申請や登録業者には GoDaddy.com を使っています。特別な理由はなく「ずっと昔からここを使っていたから」です。今回の新元号ドメイン取得は多くのライバルがいることを想定していたので、事前にシミュレーションを行って購入のリハーサルを行ったり、最短スピードで購入できるような手順を確認した上で臨みました。

(1)購入まで
そして当日、Abema TV を聴きながら(視てません。画面は GoDaddy.com にして、音声だけ聞いて、発表直後にドメイン検索できるように待ち構えてました)その瞬間を待ちます。そして発表!

・・「レイワ? レイワって言ったな?」 直後に reiwa.jp を検索(体感的にはこの間 0.1 秒)! 結果は・・・がーん、まさかの取得済み! 


後で調べてわかったのですが、千葉県柏市の「株式会社 冷和」様が 2007 年に登録済みのドメインでした:
2019041801


が、reiwa.jp が取得済みなのは(まさか一般企業が取得しているとは思ってなかったけど)想定済み、プランB発動! .jp 以外でどこか空いてないかな・・・ と探していたら reiwa.world が空いていました。

「ワールド!? うーん、ワールドか・・・ でもまあ『世界にアピールするには悪くない』よな。あと .world なら値段もそんなに高くないはず」と体感的には1秒ほど考えた後、脊髄反射的に購入プロセスへ(というわけでスクリーンショット撮ってません、ごめんなさい)。もしかしたら同じ処理をしている人が他にいるかもしれない、その場合は早いもの勝ち! でもこのあたりは直前に何度もリハーサルしてるので(苦笑)迷うことなくサクサク進めることができました。そして、、、
2019041802


取ったー!!

もうドメインを取ることだけを考えて手を動かしていたので値段見ずに買ってました(良い子は真似しちゃいけません)。ぶっちゃけ思っていたよりも高い。(^^; しかもよくわからない "Private Domain Registration" まで付けて買ってるし(苦笑)。でもいい! reiwa.world ドメイン取ったどーー!!


(2)謎のメール
上記の購入お知らせメールを受信した直後に GoDaddy.com からもう一通のメールを受信しました:
2019041803


"reiwa.world" を登録できない!? エラー!? 登録できなかったら返金する、って、いやいやいや。どういうこと??

後でわかったのですが、どうやら GoDaddy.com の受付処理が間に合わないレベルでほんの僅かに先客がいたようで、このドメインを取ることができませんでした:
2019041804


この先客の登録は日本時間で 11:42:43 、僕の登録(正確には登録メールを受信したタイミング)は 11:43:04。20秒差もあったということは、この相手はほぼ自動的にドメインを登録する処理をしていたのだと思われます。やられた・・・

そしてその先客とは・・・グーグル様でした。 凸(▼▼
2019041805


残念ですが、「個人でグーグルと張り合った」と解釈して満足することにします。


(3)返金
後日、GoDaddy.com から返金処理が行われてきました:
aeon201905


ちょっと待って!

支払額が 23558 円で、返金額が 18063 円。なんで差があるの? しかもこの 18063 円ってドメイン登録費用のみの額で、(調べずに付けて買った)プライバシー登録費用の 5495 円ぶんが返金されてないじゃん!

というわけで GoDaddy.com のカスタマーサポートに電話。ここ、いつの間にか日本語で電話できるようになったんだよね。助かります。

で、事情を伝えると「忘れてたみたい、今から返金します」的な感じで対応していただきました。 まだ入金は確認できませんが、とりあえず手続き処理は完了した模様です。


最後までドタバタしましたが、令和の前に令和の騒動を解決できたっぽいのでまとめておきました。 令和の次まで生きてたら、次回は自分も API とか探して自動化で参戦したいです。

Windows 10 でサポートされるようになった WSL(Windows Subsystem for Linux) 、しばらくメイン機が Windows 7 のままだったので、あまり使うこともなかったのですが、業務用のマシンも5月に Win10 に置き換えられることになったことと、プライベートで購入した GPD Pocket 2 を開発機として活用する目的もあって、これまで以上に気合を入れて使ってみることにしました:
windows-vs-ubuntu



【これまでの開発スタイル】
WSL の話の前に、これまでの自分の開発スタイルを簡単に紹介しておきます。基本 Linux 上でソースコードを書いて、同 Linux 上で動かしてテストしていました。最大の理由は「本番で動かす際のサーバーはほぼ Linux 」かつ「自分は vi エディタ派」だからでした。一方、業務で支給されているマシンはメイン機が Windows (7) ノートPCで、サブ機が macOS デスクトップ(iMac)、個人で所有する中に Ubuntu デスクトップ機が1台存在する、という状態でした。つまりコーディングする時は
  • Windows に Linux の仮想マシンを入れて、そちらにログインしてコーディング
  • Windows から別環境の Linux(クラウドとかラズパイとか)にリモートログインしてコーディング
  • macOS 上のターミナルからエディタを起動してコーディング
  • Ubuntu デスクトップをインストールしたノート PC からコーディング
するような感じでした。

なお Windows 上でコーディングして Windows 上で動作テスト、というスタイルは本番サーバーが Windows とわかっていればやるかもしれませんが、色々挙動の違いが気になってしまい、あまりやっていません。

上記4つのうち、上2つは面倒なんですが、本番環境に近い Linux 上での動作確認までできるという点が魅力です。また開発以外の資料作成時にデスクトップアプリ(パワポ、エクセル、ノーツ、画像リタッチ、あと ATOM みたいな IDE 環境、etc・・・)を利用する際においては使いやすい Windows 版が使える点が魅力でした(ぶっちゃけ、macOS 版のエクセルや日本語変換の完成度って・・・(^^; )。一方で実質的には開発用に(仮想的な)別環境を1つ作る必要があるため、ディスク利用効率もよくないし、その点においては資料作成含めてすべて1台の macOS 内で完結できる3つ目の開発スタイルも、これはこれで優れていると感じていました。 4つ目の Ubuntu デスクトップ機を使うのも3つ目と同じで悪くはないのですが、やはり開発作業以外のデスクトップ作業では Windows に一日の長があるように感じます(Micorsoft Office も Linux 版は提供されてないし)。Ubuntu でプレゼン資料作るのはまだちと厳しいと感じる現実があります。


【WSL を併用した開発スタイル】
今回 WSL を使って開発環境を構築するにあたり、このような責任分担を行いました:
サーバー部分: WSL
開発・デスクトップ作業: Windows


つまり、ソースコードを置いたり、アプリケーションサーバーを起動したり、そのアプリケーションサーバーから開発したアプリケーションを起動したりする部分は WSL を使います。 一方、ソースコードを編集したり、ソースコード以外の資料ファイル作成など(ウェブでググるのも含める)といった GUI のデスクトップ作業は Windows を使うことにします。それぞれの得意分野を活かせるような分担にしたつもりです:
2019040800



この環境で開発作業を行うために2点ほど環境設定を行いました:

(1) ソースコード共有
サーバーが WSL で、クライアントおよびデスクトップ作業は Windows 。と、キレイに分けているように見えるかもしれませんが、ソースコードだけは共有する必要があります。つまり Windows(クライアント)側でソースコードを編集し、その編集されたソースコードが WSL 上で実行される必要があるのでした。

このため以下の手順を実行して、Windows / WSL 両方の環境から1つのソースコードが参照できるようにしました。まず Windows のコマンドプロンプトを起動し、ホームディレクトリに src/ という名前のフォルダを作成しました。ソースコードはこのフォルダ内に作ります:
> cd \Users\(Windows のユーザー名)

> mkdir src


次に WSL のシェルを起動して、上記で作成した src フォルダをホームディレクトリにシンボリックリンクします。WSL からは Windows の C ドライブが /mnt/c/ フォルダにマウントされています。この情報から上記で作成したフォルダは /mnt/c/Users/(Windows のユーザー名)/src に作られていることになるので、WSL のシェル上で以下のように実行します:
$ cd

$ ln -s /mnt/c/Users/(Windows のユーザー名)/src

これで Windows のホームディレクトリ以下に作成した src フォルダが、WSL では ~/src フォルダとして存在するようになりました。これで Windows で編集したファイルを WSL からも参照できるようになったので、そのまま WSL のアプリケーションサーバー上で動かすことができるようになりました。


(2) ATOM エディタの vim 化
次に Windows 向けのテキストエディタのカスタマイズです。個人的に vi/vim 派なので、テキストエディタでもこのキーバインドを使いたいのでした。

例えば Windows 向けの vim を導入する、というのも1つの案だと思いますが、自分は ATOM エディタに vim 用プラグインを導入して vim っぽく(?)使えるようにカスタマイズしました。

具体的には(ググればわかると思いますが)ATOM エディタに vim-mode-plus プラグインを導入して、ATOM を vi/vim キーバインドで使えるようにしています。


これら2つのカスタマイズによって、
①アプリ開発時に、まず Windows で WSL と ATOM を起動し、
②ATOM でソースコードを編集し、
③WSL 側で編集したソースコードをアプリケーションサーバーで起動してテスト、
④Git へのコミットや本番サーバーへのデプロイは WSL から行い、
⑤ドキュメントや資料は Windows の Office やデスクトップツールで作成
という、かなり使い勝手のよい作業分担環境を作ることができました。

一方でこの環境を使う場合の注意点もあります。最大の問題は「文字コードの違い」を意識する必要があることです。Windows 側で編集するソースコードの文字コードは原則 UTF-8 にする点に注意しましょう。

WSL はまだ動かないツールがあったり、デーモンは手動起動が必要になるなどの制限事項もありますが、ウェブアプリケーションの開発環境として使う限りにおいてはあまり苦にならないと思いました。


小型コンピュータのラズベリーパイ、一般的には Raspbian OS で使われることが多いと思っています(自分も特別な理由がなければ Raspbian OS か、または Raspbian の派生 OS で使います)。

が、Raspbian OS って 32bit OS なんですよね。ラズベリーパイ自体は 64bit CPU である arm64 を搭載していることを考えると、「せっかくなので 64bit で使いたい」ともなるわけです。

ラズベリーパイ上で動く 64bit OS はいくつかあるようです。ただリストを見ると「64bit 機能の一部が動かない」という注釈もあったりして、全てが期待通りの挙動をするかというと、そうでもなさそう・・・

というわけで、ラズベリーパイに 64bit Linux である openSUSE を導入する方法を紹介します。といっても導入だけなら Raspbian OS と特別に違うことはなく、どこからイメージをダウンロードするか、程度の違いですけどね。


ラズベリーパイ向けの openSUSE イメージをダウンロードするには、SuSE のラズベリーパイ用ページを参照します:
2019040202


下にスクロールすると、ダウンロードイメージへのリンクが現れます。いくつか種類がありますが、Tumbleweed(開発版)か Leap(安定版)を選び、デスクトップの種類を選択してイメージをダウンロードします。ちなみに僕は Tumbleweed の E20 image を選びました:
2019040201


後は Raspbian OS と同様でダウンロードしたイメージを展開し、(DDWin などのツールを使って)MicroSD カードに書き込み、そのカードをラズベリーパイに差し込んで起動します。

デフォルトのままであれば ID: root, PW: linux でログインできます:
shot-2019-04-02_23-08-13




このページのトップヘ