JANOG41.5 Interim Meetingにお邪魔してきた

4/20に行われましたJANOG41.5 Interim meeting に参加してきたので軽く報告です。

JANOGとは

ネットワーク界隈の方からすると有名だと思うんですが、JANOGはJapan Network Operator's Groupの略で、国内のネットワークおよびインターネットを支える企業、研究者が集い、最新技術や運用について報告し議論するといった内容のイベントです。お話を聞きたかったので今回初参加してきました。

www.janog.gr.jp

ちなみにjanogをはじめとするこういったイベントの中では、同士の集まりのことをBoF(Birds of a Feather)というようです。かっこいいですね。

おはなし

様々なネットワークベンダーさん、ISPさん、大学のネットワーク管理者さんが数分の持ち時間で調査、研究、活動の宣伝を行っていました。

内容としては某W大学の無線ネットワーク構築は多数のキャンパスがある為、WLCを使うと逆に大規模な無線環境の更改しかできなくなって悩みどころなんですよねー、とか、JPNAPは広島でBoFやってきました、とか、conbuでイベントの無線LAN環境構築に参加してみませんか、とか、テレメトリネットワーキンググループが発足しました、とか、JANOGスタッフやってみませんかー、とか、AnsibleをPlaybook無しで気軽に使う方法、とか。。。他にも各ベンダーさんや企業のインフラエンジニアさんのお話を多数伺ってきました。twitterでもちょっと盛り上がりを見せていましたね。。

とんでもないところに来てしまった #janog pic.twitter.com/Sy9J1gWTMe

— Koji Saiki (@saikou9901) 2018年4月20日

そんな感じ

初参加でしたが非常に活気のあるイベントでした。

twitterのハッシュタグを追うと詳細がまだ見られるのかな？少なくともjanog公式サイトには当日の講演資料が一部掲載されていますので、興味のある方はご覧になるといいかもしれません。また、次回のjanog 42は三重県での開催です。ハッカソンもやるかもしれないそうですよ。

https://www.janog.gr.jp/meeting/janog42/

おまけ

めっちゃオフィスとセミナールームは綺麗でした。。日本にこんな職場があるんだなって思った。

node.jsの3つめのメモ

node.jsの最初のメモ - brand new note

node.jsの2つめのメモ - brand new note

前回(というか昨日の夜)の続き。とりあえずなんか画像を出してくれるやつを考え中です。記事書いて頭の整理をしながらでないとうまくいかないので、もはや他人様の読み物じゃないです。

記事一覧

使えそうなリンクのメモ。

node.jsを使ってサーバサイドで画像合成してみる (node-canvas編) |

ウェブでの画像ファイルの取り扱いについて (Node.js * javascript)

Node.jsで画像アップロードと表示 - Qiita

Expressことはじめ - Qiita

イマドキのJavaScriptの書き方2018 - Qiita

メモ

まず前回の記事と同じ手順をもっかい踏んで環境を作ればいいんですかね、ポートを変えて。写経の繰り返しなのでどこからが自分の実力なのかはっきりしないですね。。。自分の頭の中だけで完結できるもの、手が勝手に動く状態を少しずつ増やしていく感じでしょうか。

npm init して npm install express --save. モジュールをロードする、ポートを指定して待ち受けを開始する、アプリケーションの処理を書く。

app.get()はappオブジェクトのgetメソッド。

resはレスポンスを返す。res.json(picturelist)はjson形式で画像のリストを返す。()の中は var picturelist のことを指すのでここで名前を揃える。

ちょっとずつサンプルを変えて動かしてみてうまくいかなかったら原因を考える。

というか画像なりテキストなりをちゃんと読み出せているかの確認が出来てないんですよね。これをやって。。。

できない。。。。

constが変わらない数でletが変わる数

アップロードしたら、したものの画像をリスト化して出してくれるようなやつがいいですかね。アップロードボタンが必要。

app.jsと同じディレクトリに画像があれば良くて。

...あれだな、他のサンプルコードからも学習できることがありそうなのでそれからだな。。

node.jsの2つめのメモ

前回の記事はこちら

node.jsの最初のメモ - brand new note

とりあえずインストールはできたので、本記事ではExpressを導入とサンプルの写経でアプリ開発の基本を押さえてみます。といっても下の記事をなぞっているだけなので、こちらも個人的メモの域を出ていません。本記事を読まれる方は併せて下の記事をしっかり読んで頂くといいと思います。

qiita.com

Express

node.jsのフレームワークの王道。REST APIとかと組み合わせるといい感じに開発できます。REST APIは、ざっくり言うとURIの末端をID化することによって同一ドメインで多様な処理を行えるようにする機能です。でも初めて知ったのでこの説明が正しいかちょっと不安です。

0からREST APIについて調べてみた - Qiita

例えば写真や画像のリストを表示するサイトを作ってみたい場合、沢山の画像にIDをつけて管理できれば便利ですよね。URI解析用のコードを書かなくても、node.jsとExpressを使えばシンプルなコードで実現できるようです。

まあ詳しい話は分からないのですが、とにかく便利だから有り難がって使おうということですね（適当）

ディレクトリ作成

まず作業環境を作ります。ほんとはこのあたりをまとめてやってくれるツールもあるんですが、理解のため記事に沿って手作業でやってみます。

mkdir node
cd node
npm init

npm initでプロジェクトを初期化し、いくつかの質問に答えるとそれに合わせたpackage.jsonファイルが生成されます。プログラムの作者のところに名前を書いたりとか、gitのリポジトリを指定したりとかですね。

次にExpressをインストールします。

npm install express --save

--saveをつけるとpackage.jsonにexpressを使っていますという内容が追記されます。

プログラムを書く

サーバ側の処理、クライアント側の処理を分けて書いていきます。参考記事に沿って書いていくと、サーバサイドの処理というのは「画像を保存している場所を参照し、その画像をリスト化してIDをつける」部分を表しているようです。

逆にクライアント側の処理というのはサービスを使う側ができる操作の部分を表しますから、この場合「画像をIDによって検索し選択する」部分となります。で、サーバ側の処理とクライアント側の処理は「app.js」に書いていきます。もちろんデフォルトのファイル名なのでこの名前以外でもできます。

また、UI(ユーザインターフェース)の作り込みに関しても別に作っていく必要があります。これはwebサービスなので主にHTMLとかでいけます。他にもあるみたいですが。。。こちらは「views」ディレクトリ配下に「index.ejs」ファイルを作ることによって実装できます。もちろんデフォルトのディレクトリ名なのでこの名前以外でもできます。

以下写経。

app.js

index.ejs

詳しいコードの内容はちょっとまだ説明できないので元の記事を読んでもらえればと思います、ごめんなさい。

これらを実行してみたところ、とりあえず参考記事と同じような出力結果を得ることができました。3000番ポートを開けてnode app.jsで実行、ブラウザでhttp://localhost:3000にアクセスすると「New Project」が表示されます。この表示はhtmlで記述した「index.ejs」の内容です。F12キーでjavascriptコンソールを確認してみると、サーバの処理がクライアント側で呼び出されていることを確認できます。photo001,photo002といった画像ファイルの部分がリスト化されて読み込まれています。

おわりに

とりあえずNode.jsのさわりの部分である「クライアント、サーバ、UIを分けて実装する」といった空気感はこの参考記事でかなりつかめるのではないかと思います。写経しただけでは実際に画像を表示できるわけではないですが。。。

また、こうした「app.js」「index.ejs」などなどのワンセットは、「ミドルウェア」で生成することが可能です。同じ方が書かれている下の記事も、順番に読んでみると理解が深まると思います。

Express + Node.jsで基本を理解した次の一歩 - ディレクトリ構成をルーティング・ミドルウェアを理解して考えてみる - Qiita

ここから自分なりに少しずつ理解を深めて、まずはローカルで何かしら動くサービスを作れたらいいなと思います。

node.jsの最初のメモ

1年前にもnodeとかphpとかをやりたくてちょっとだけ書いたことはあるのですが、結局アイデア不足と「プログラミングのこころ」が理解できず挫折。Cだけやってても面白そうなものがすぐには出来そうにないので、ちょっとwebの勉強をします。ずっと前から言ってるのにいつになったら覚えられるのだろうか。。。なお本記事はqiitaを読んだだけの自分用のメモですので、より理解したい方は参照記事及び他サイトを参考にしてください。

node.jsとは

qiita.com

node.js

サーバサイドのjavascriptで、I/Oの処理結果を待たずに処理をするノンブロッキングI/O。

1万台問題っていう処理能力の問題があって、ノンブロッキングI/Oによってこれを解決できるらしい。ストレージの読み書きスピードはCPUやメモリに比べて非常に遅いので、ストレージに書き込めたかを待たずに処理を進める。書き込めたやつからコールバック関数を使って処理する。

キッカケの命令を出すことで動き始める(event driven)つまりクライアントがアクションを起こすことでサーバの中の待機中のプログラムが動き出す？

シングルスレッド

javascriptエンジン（これがなんだかわからない）がgoogle v8ってやつなので高速

アプリの特徴

小さい計算なら早い

メモリを食わない

ローカルとリモートのやり取りをシームレスに行うフレームワークがある

server,clientで処理の共通化ができる

リアルタイム性のあるアプリケーションにあう（常に何か監視し続けていて、的な？）

websocketを使うアプリに合っている

プラットフォームです

nodejsはフレームワークではなくjavascriptアプリケーションのプラットフォーム。フレームワークは開発をするとき便利だから再利用するやつ、プラットフォームは実行ができる環境のこと。言語そのものではない？？？

framework

Express,Backbone.js,Sails,Meteorなど

これを使えば0からじゃなく容易に開発できるってことですかね

用語

• callback関数(非同期の処理が終わったら呼ばれるやつ)

• CommonJS(共通化しようとしている規格)

• libuv (libev,libeio)非同期I/Oライブラリ、イベントループライブラリ

• DIRT: データインセンティブリアルタイム

• npm: node package manager,モジュール管理

クライアントサイドjavascriptとの違い

• require

• module

• npm

• C/C++プラグインで拡張できるらしい

んーー前に比べたら何を言ってるか理解できるようになった気もします。

インストール

自分のPCがCentOS7なのでこちらを参照します。

qiita.com

最新版をここから確認。

distributions/rpm at master · nodesource/distributions · GitHub

sudo yum install -y gcc-c++ make
curl -sL https://rpm.nodesource.com/setup_9.x | sudo bash -
sudo yum install -y nodejs

インストールできたかどうかバージョンを見て確認します。

これで準備ができました。次以降の記事でなんか作っていこうと思います。

node.jsの2つめのメモ - brand new note

manページの番号が持つ意味

ずーっと疑問だったのがちょっと解決したのでメモ。まずmanページに番号がなぜ必要なのか、加えて番号を使うことでどのようにコマンドを扱うことができるのかについて書いていきます。

manページに番号がある意味

コマンドのマニュアルであるmanページですが、たまに番号つきで説明が出てくるコマンドに遭遇します。これが何なのかまず簡単に言うと、こういった場合「同じコマンドなんだけど複数の意味、使用用途がある」ということを表しています。同音異義語と似ていますね。例としてtimeコマンドを見てみます。

# man 1 time

# man 2 time

timeの一つ目の意味としては「コマンドの時間計測やリソース使用量を表示する」、二つ目の意味としては「秒単位の時間を得る」とあります。このように複数の意味が存在するコマンドは、”man 数字 コマンド” でそれぞれの意味を確認することができます。これだけ知っていればしばらく困らないとは思いますが、ここで注意してほしいのは「コマンドの使い方が複数ある」ではないということです！追って説明します。

manページの番号が持つ意味

えっでもどっちも時間見てるだけじゃんと思った方、ここで上図の「書式」を見比べてみてください。1ではコマンドの文法が書かれているのに対し、2ではＣ言語らしきものが書かれていることがわかります。

システムコール

そもそもUNIXのコマンドはＣ言語を基にして作られています。またOSの様々な制御は「ユーザモード」と「カーネルモード」の2つを用いて行われており、ここを命令が行き来することによってプログラムは動作しています。

普段プログラムはユーザモードで動作しているのですが、ハードウェア(CPU)に直接命令を下したい場合はその都度「システムコール」を使ってカーネルモードにアクセスします。

ちょっと説明のために脱線しますが、ここでlsコマンドの内部でどのようなシステムコールが行われているか確認してみます。

なんかexecveとかopenとかmmapとか書いてありますね。これが全部システムコールです。要するにlsコマンドを打つだけで、内部ではこれだけの回数カーネルモードに遷移しているのです。これらが何なのかは細かい説明になるので書きませんが、ここで下のコマンドをちょっと試してみてください。

man 2 execve
man 2 open
man 2 mmap
man 2 mprotect

書式の所がC言語になってmanページが表示されたでしょうか？

つまり、manページの2番はシステムコールの説明をしているのです。通常のコマンドとしてのtimeはその場で時間を測定する効果をもたらしますが、システムコールとしてのtimeは、何かのコマンドを実行した時に「そのコマンドが内部的に何かの時間を計測した上で結果を返す」というような挙動をする時、使われているという事なのです。

manページの書式内のC言語はシステムコールの実装そのものであり、コマンドはC言語で作られたシステムコールの集合であるということがお分かりになると思います。

番号と意味の対応

マニュアルの番号はセクションと呼ばれます。1、2以外にもありますので記載しておきます。また、OSによってこれらの番号の振り分け方は異なる場合があります。

• 1:ユーザコマンド

• 2:システムコール

• 3:システムコールを除くCライブラリ関数

• 4:デバイスファイル

• 5:設定ファイルなどのフォーマットについて

• 6:ゲームプログラム

• 7:その他の概要などの説明

• 8:システム管理コマンド

例えば1のユーザコマンドだったらlsとかcpとかが含まれますし、4のデバイスファイルだったらnullとかzeroとかttyとかが該当します。*1 一つしかコマンドの意味が存在しない場合はそんなに気にしなくても参照できますが、こういうのがあるとだけ分かっておくといくらか読みやすくなると思います。

おわりに

コマンドを覚えて操作できることを目標とする段階ではなかなか理解しにくい面があるかもしれません。linuxの内部的な話をいろんなところで少しずつ読んで理解すると、このあたりの話も納得できるのではないかと思います。

あ、偉そうに書きましたが間違っていましたら御指摘お願いします。僕も勉強中の身ですので。。。

*1:/dev/zeroってなんだ - brand new note

Windows Subsystem for Linuxを使ってみる

かつてbash on ubuntu on windowsと呼ばれたWindows Subsystem for Linuxをインストールしてみました。

WindowsでLinuxが使える？？

Windowsの中でLinuxを使えたらもっと手軽にいろいろ試せるのに、、と思った途端、そういえばなんかあったなあと思い出したのでインストール。まあ特にこれといってやりたいことはないんですが。動作したはいいものの、どういう仕組みで動いているのか気になったので調べました。

仮想化とは違うのか

/mntディレクトリを見てみると、CドライブやDドライブがあるのを確認できます。仮想化とは違って本当にWindowsとシステムが共存しているようです。IPアドレスも確認しましたが、Windowsで使っているいつものアドレスと同じ値が使われていました。VMWare Network Adapter VMnetのアドレスもそのまま使われていました。

調べたところ、現在のwindowsはマイクロカーネル(UNIXのようなモノリシックカーネルと違い、カーネル部を最小にしてその他多くの機能をモジュールとして読み込む考え方)で動作しており、その上に複数のサブシステムを共存させることができるようです。いつものGUIもwindowsサブシステムと呼ばれるもので、これに沿ってLinuxもサブシステム化して動作させることは可能というわけです。

Windows Subsystem for Linux(WSL)はPicoプロバイダードライバという2つのカーネルドライバで実装されており、Windows側でlinuxセッションマネージャサービスがWSLのセッションを呼び出し、その先でbashをforkするという流れになっているようです。下図はmicrosoftのブログから引用しています。

何が便利なのか

まず仮想化に比べると、ファイルの転送がとても楽です。一応Cドライブの中身は/mntに入っていますがそれ以外はまっさらなので、/homeなんかには何も入ってません。なのでその中でlinuxでやりやすい作業をして、その後作ったファイルを/mnt配下に持っていくことで簡単にデータの共存ができます。

加えてネットワーク構成がwindowsとほぼ同じなので、デスクトップ環境でターミナルソフトを立ち上げるところを、sshコマンド一発で入りたいサーバに入れます。それらのサーバとファイル転送をしたいときもwinscpとかいちいち立ち上げなくて済みます。これほどちょうどよくwindowsとlinuxの使いやすいところのいいとこ取りができる技術があったなんて。。。

今のところ自分が見つけたのはそのくらいですが、特にプログラムを書く人にとってはこの恩恵を大きく受けることができるのではないかと思います。officeで資料作りながらコマンドラインで開発できるわけなので。

はじめの一歩に使えるリンク

インストールのしかたと概念はこのへん読めばいけます。

• Windows Subsystem for Linuxをインストールしてみよう！

• Windows Subsystem for Linuxとは？ そのインストールと使い方 - Build Insider

• [ThinkIT] 第1回：歴史とアーキテクチャを比較してみる (3/3)

• Windows Subsystem for Linux Overview – Windows Subsystem for Linux

root取れない問題

一瞬詰まる方も多いので参考までに。WSLでルートが取れない問題に関しては、こちらの情報が有効です。

bash on Windows の root のパスワードは | Windows 10

初期パスワードは不明とのことですがsudo は効くので、次のコマンドによってrootパスワードは自分で変更できます。

sudo passwd root

OpenstackとAnsibleの関係性がわからないので調べた

タイトルの通りです。最近よく聞くAnsibleっていうのが何なのかさっぱり分からず、自動化とか構成管理とかいう言葉と一緒にに流れてくるのを見てOpenstackっぽいサムシングを連想したんですがどうなのか。技術的なことは書いてませんが、調べているうちに背景や今の流行がなんとなくつかめたのでその辺を網羅的にメモします。

とりあえず読むじゃん

qiita.com

www.ntt-tx.co.jp

AnsibleによるInfrastructure as code入門 from kk_Ataka

www.slideshare.net

Infrastructure as a Code

Infrastructure as Code（IaC） というのは、物理的なハードウェア構成やインタラクティブな設定ツールの使用ではない。コンピューティング・インフラ（プロセス、ベアメタルサーバー、仮想サーバー、など）の構成を管理したり、機械処理可能な定義ファイルを設定したり、プロビジョニングを自動化するプロセスである。

Wikipediaより。DevOpsとの関係性の部分ではこのように記されています。

IaCはDevOpsのベスト・プラクティスを実現する重要な要素だろう。開発者はもっと構成の定義に参加するようになり、運用チームは、開発プロセスの初期段階で入ってくるようになる。IaCを活用するツールはサーバーの状態・構成を視覚化し、企業内のユーザーに視覚性を提供し、最終的に努力を最大限にするために、チームを結集することを目指している。 一般的に、自動化は、手作業のプロセスの混乱とエラーの起こりやすい部分を取り除き、より効率的かつ生産的にすることを目指している。手動構成の効率を低下させる複雑さを軽減することも目的としている。柔軟性が高く、ダウンタイムが少なく、全体的に費用効果が高いソフトウェアとアプリケーションを作成できる。 自動化と共同作業は、DevOpsの中心的なポイントであるため、多くの場合、インフラストラクチャ自動化ツールはDevOpsツールチェーンのコンポーネントとして含まれている。

要するにクラウドサービスが盛んになった現在では、開発から運用までをチーム一体となってカバーすることが容易になった。それに伴ってサービス設計の初期段階である「インフラ構築のフェーズ」を様々な技術者に理解してもらいやすくすることが必要となってきた。その為にあれこれを自動化、可視化してより簡単に扱えるようにしよう、という思想が広がり、これがInfrastructure as a Codeと呼ばれるようになった。

で合ってますかね！？

いっぱいサーバが並んでるところで一台一台手作業でソフトを入れたりするのはありえんしんどいので、すべてのサーバが同じ挙動をする仕組みができれば一発で大規模システムも管理できて幸せだよね、という話なんでしょうか。そういえば米microsoftは一人当たり数千台のサーバを管理しているとかいう噂を本で見たのですが、確かにこういうところでならかなりの効率化が期待できますよね。その構成管理のツールのひとつがAnsibleなんですね。

インフラ屋もコードを書くのか

他の構成管理ツールであるChefの場合はRubyベースの定義ファイルに基づく設定が必要です。しかしAnsibleの場合、yamlというマークアップではないけどプログラミング言語でもない記述方法によって簡潔に設定ができるようです。Ansibleの実装はPythonなので詰まったら実際のソースを読んでデバッグすることはあるんでしょうけど、特にPython書けなくても動かすことはできます。これなら俺にもできるだろうか。。。

ぼんやり「インフラエンジニアもこれからはコード書けないといけないということ…？」と思っていましたが、そうともいえるしまだそうでない仕事もある、でもできないと時代に取り残されるかもしれない、という認識です。学ばねばならぬ。

OpenstackとAnsibleの関係

OpenstackのモットーはVMそのものを構成する部品を作る(ブロックデバイスやネットワークIO、認証系など、コンピュータとして必要な機能をまず提供する)とでもいうべきでしょうか。そして、その中で提供する部品の一つに「自動化を助ける機能」があり、ここでChefやAnsibleといったツールが連携します。ソフトウェアの導入、サービスに応じたネットワーク設定等をするための機能です。Openstackの上にAnsibleがのっかっていて、その上に開発するサービスが動くということでしょうか。

またAnsibleはその特性から、短いスパンで改良を遂げているOpenStackとは思想が近く、相性がいいようです。Ansibleは構築したサーバにエージェントを置く必要がなく、端末からsshで設定を流し込むだけで柔軟かつ容易に構成の自動化を行えるからです。逆にあまりにも大規模なサービスの場合はエージェントを置いたChefのほうが良いみたいですね。