おれ、エンジニアになるよ。

エンジニア志望の大学生がISUCON7出場を目指す成長日記

「サーバ/インフラエンジニア養成読本」を読んで 〜SSHでCentOSにログイン〜

こんばんは。

今回は、よく使われる「SSHでログイン」について。

 

........??(はい出たー、ナニソレ的なやつー)

 

 

まずは前回したサーバOSの話をちょこっと。

 

matsuda-juri.hatenablog.com

 

実は、サーバOSは直接サーバ本体を操作しなくてもイジイジできちゃうらしい。

1台のPCに仮想環境を用意して、その上でサーバOSを動かすんや。

 

 

.......??(仮想環境ってなんや)

 

 

超簡単に言うと、1台のPCにもう1台PC作っちゃおう的な。

このもう1台のPCが仮想環境で、使うには仮想化ソフトウェアを導入する必要があるみたい。

Oracle VM VirtualBoxとか。

無償だし情報もいっぱいあるしね。

 

話を戻すと、このVirtualBoxCentOSを入れたらもう1台のPC完成ってわけ。

 

 

 

よし、SSHでログインしてみよう!

 

SSH

secure shell

 

SSHとは暗号化された通信で、ネットワークを介してリモートアクセスするのに使うんやって。

暗号化されてるから安全な通信が可能らしい。頼もしいね。

 

 

SSHを利用するにはSSHサーバが動作していることが条件。

この設定の話はちょっと今回割愛でwww

 

サーバがあるってことはクライアントよねー。

ってことでSSHクライアントが必要になるわけやね。

 

代表的なのがこれら。

 

・Tera Termttssh2.osdn.jp

 

PuTTY

http://www.chiark.greenend.org.uk/~sgtatham/putty/

 

Macターミナル

 

 

これらはターミナルエミュレーターって言うらしい。

 

ちなみに、

ぼくはこのターミナルエミュレーターって言葉知らなくて、

 

「このコマンドどこで打ちゃいいんだぁぁぁぁぁっぁぁっぁ」

 

ってなったことがありますwwww

 

まぁまぁそこは置いといて。

実際にTera Termを使う場合どうやるか?

 

Tera  Termでサーバにアクセスするには、

サーバのホスト名IPアドレスが必要になる。

 

 

.......ごめん。

もう気付いてるかもしれないけど、文字だけじゃ説明しにくいwwwwwww

 

 

ってことで最後にもう1回「SSHでログイン」のおさらい。

 

ぼく(クライアント):「マササーバにログインしまーす!!」

マサ(サーバ):「ホストの指定は.....うん、合ってるね。パスワードもOK! ようこそ

         マサワールドへ!!」

 

こんな感じwwwww

 

では、今日はこの辺で。

「サーバ/インフラエンジニア養成読本」を読んで 〜新人エンジニアのための基礎講座〜

こんばんは。

昨日まで就活で東京に来ておりました。

突然ですが、ぼくの就活スタイルはズバリ、

 

「スーツ絶対着ない!」www

 

 

もちろん、今回行ってきた4社とも私服で参加しました。

この私服only主義がモロに出たのが、1社目。

私服参加OKのとこだったので問題はありませんが、見事にぼくだけ私服。

 

ちょー気まずかったwww

 

しかし、ここで怖気付かない。

堂々と一番前の席に座ってやりましたよww

 

1次選考も無事に通過したので結果オーライです。

 

 

 

さて、今日からこのブログでまとめる本は、

「サーバ/インフラエンジニア養成読本」

 

改訂3版 サーバ/インフラエンジニア養成読本 (Software Design plus)

改訂3版 サーバ/インフラエンジニア養成読本 (Software Design plus)

 

 

ちょっと難しそう。

でも頑張るよし!!

 

 

WindowsLinuxの違い

 

みなさんの初めてのPCは何でしたか??

ちなみにぼくはMicrosoftSurface Pro2でした。

 

そんなSurfaceシリーズのOSはWindows

 

Windows

 

Windows OSの一番の特徴は、

 

GUIが整備されている

 

ということ。

 

GUIとは、Graphical User Interface

簡単に言うと、マウス操作を基本としたグラフィカルな画面でわかりやすく情報のやりとりができる。

 

また、エディタで設定ファイルを書く必要がないから、設定に自信がない人には使いやすらしい。

 

けど、複数のサーバにちょこっと(または同じ)設定をする場合は、サーバごとにラインセンス費用がかかってしまうのがちょっとめんどいところ。

 

Linux

 

そもそも「Linux」って言葉、聞き慣れないよね。

そもそものそもそも、よく耳にする「windows」とか「mac」ってのはOSのことを言ってるんやね。

windowsが入ってるPC」って言うでしょ?

 

このLinuxも同じOSのことなんだけど、無料なのだ。(商用の場合はライセンス費用がかかる)

ちなみに、

 

無料Linux

・Cent OS

Fedora

Ubuntu

など

 

有料Linux

Red Hat

SUSE

など

 

 

話を戻すと、Linuxの一番の特徴は、

 

CUIが整備されている

 

ということ。

 

CUIとは、Character User Interface

 

テキストベースで基本操作するので、自動化が簡単で、大量のサーバを管理する場合は圧倒的にLinuxの方が楽らしい。

 

黒画面に緑文字で、英語がガァーっと並んでるのイメージすると分かりやすいかな。

 

また、GUIがない分メモリを無駄に消費せず、高速な処理と、サーバの性能を最大限に使い切ることが実現できるんやって。

 

 

ミドルウェア

 

これはOSとアプリケーション実行環境の間に入って、動作を仲立ちしてくれるソフトウェアのこと。

実はここ、過去記事で書いたおかみさんとか職人さんのことを言うんよね。

 

その記事がこれ↓

matsuda-juri.hatenablog.com

 

 簡単にミドルウェア名を紹介しておくと、

 

Webサーバ(おかみさん)

→ Apache , Nginx , IIS

 

Appサーバ(職人さん)

→ Tomcat , JBoss , Unicorn , Gunicorn

 

DBサーバ(素材屋さん)

→ Oracle , PostgreSQL , MySQL , SQLserver , DB2

 

これら3つまとめてミドルウェア

今後超使うからこの言葉は覚えておこう。

 

 

キリがいいので今回はここまで。

次回は「仮想環境・Cent OS」からやっていきます。

 

 

 

そもそもなんでお前ISUCON出んの?

こんばんは。

本日2度目の投稿ですww

 

1冊目終わりちょうどキリがいいので、ここらでISUCON出場のきっかけや関係者について書いていこうかなと。

 

 

ISUCON出場のきっかけ

 

ちょうど2週間前。

とあるプロジェクトで一緒に開発していて、色々教えてくれる先輩エンジニアのさぼさんって方がいてですね。

 

さぼさん:「ISUCON出たら就職できるよ?ww」

ぼく:「は、はい......。(イスコンってなんだ?むしろ美味そうじゃないか!!)」

 

こうなったわけですよww

ちょうどその頃のぼくはと言うと、就活真っ最中で、渋谷ヒカリエにオフィスがある会社に落ちたとこだったんですねー。

就活振り出しになったぼくは、会社選びについてさぼさんに相談していたところ、さっきの会話になったというわけですw

 

そもそもですが。

ISUCONってのは競技プログラミングの大会で、毎年9月にLINE本社で行われます。

予選・本戦があって、本戦に勝ち進んでくる人たちはいわゆる「ハイパーなエンジニア」と呼ばれる方たちです。

しかしこの人たちは「一般枠」。

実は「学生枠」ってのもあるんですね。

 

どうやらさぼさんがおっしゃるには、予選までの半年間、基礎からみっちり勉強すればこの「学生枠」での本戦出場は可能であると。

しかもさぼさん自らがコーチングしてくれると。

 

ぼく:「はい、やります!」

 

ちょー単純wwwwww

 

こうしてさぼさんをコーチにお迎えして、ぼくのISUCON出場向けての成長物語が始まったわけです。

 

 

 

ぼくと心中してくれる2人の仲間

 

こうしてISUCONを目指すことが決まったわけですが、早速問題が。

1人では出場できないのですwww

 

ってことで仲間集めから。

このときぼくの頭にはとある1人が浮かび上がりました。

 

ちょくちょくこのブログでも登場する「マサ」ですwwwwwwww

 

間髪入れずにマサに連絡。

 

f:id:matsuda-juri:20170417190536p:plain

 

このあとめっちゃ煽りましたw

多分彼は今まででとてつもない煽りを受けたことでしょうwww

(ごめんねマサw)

そんなこんなして

 

f:id:matsuda-juri:20170417190804p:plain

 

 

マサ、鼻血プシャーー!!!

 

ぼくはその時思いましたね。

「一人目確保」。

 

その後日、マサさぼさんと会って色々説明を受けて、正式に仲間になりましたwwww

 

 

問題はあと1人。

結構デキる学生エンジニアを口説きにいきますが、ぼくらの実力を値踏みしてか、口説き失敗に終わりました.......。

 

まずい。あと1人......。

 

とりあえず2人でスタートし、ISUCON出場への第一課題。

 

さぼさん:「よし、まずはMac買おう。」

ぼくマサ:「了解です!」

 

こうして8ギガのi7Macを買って第一課題クリアwwww

 

そうこうしてるうちにコンサル会社のインターンシップが。

そこである一人の男と出会う。

 

Youtuberのマギー

 

一時期Youtubeで稼いでたらしいww

 

そんなマギーとぼくはインターンで一緒のグループになり、突然

 

マギー:「プログラミング好きなんです。学部も情報工に変えました。」

ぼく:「お、おう.....。(なんやこいつ。告白する相手間違っとるやろ。)」

 

あんまりに突然だったのでぼくは思考停止状態。

そして我に返った時、ピンときた。

 

ぼく;「(こいつも道連れや)」

 

マギーにISUCONのこと話すが、彼は自信なさげww

どうにかこうにか口説く(煽るww)が、最後の「Yes」が出てこない。

ここで最終手段。

 

ぼく:「とりあえずさぼさんに会ってみたら?」

 

すると

 

マギー:「じゃあ、やります!」

 

こうしてぼくと心中してくれる2人目の仲間が加わったのですwww

 

 

フリーランス学生のぼく、セブんちゅのマサ、そしてYoutuberのマギー

先輩エンジニアのさぼさんの指導の下、精一杯やっていきますのでどうか温かく見守っていただけるとありがたいです。

 

 

 

人物紹介

 

・さぼさん

saboyutaka.hatenablog.com

 

 

 ・マサ

masa-world.hateblo.jp

 

 

・マギー

twitter.com

 

「プロになるためのWeb技術入門」を読んで 〜Webシステムの三層構成〜

こんにちは。

「プロになるためのWeb技術入門」シリーズ、今回が最後です。

 

テーマは「Webシステムの三層構成」。

・Webサーバ

・・・女将さん

 

・Appサーバ

・・・職人さん

 

・DBサーバ

・・・素材屋さん

 

こいつらが互いにあんなことやそんなことやこんなことまでしてるんやって。

んで、この3つはシステム開発する上で必ず登場するみたい。

ソフトウェア構成の基本の基本の基本のそのまた基本。

絶対押さえとかなきゃいけないね。

よし、やろう!

 

 

と、サーバの話の前に「ノード」について。

 

 

ノード

 

一つのシステムを動かすために、Webサーバ・クラインアントみたいに複数のコンピュータがあった。

この時、各コンピュータのことを「ノード」って呼ぶらしい。

コンピュータの他に、ハブとかルータもそう。

まぁここはさらっと。

 

 

では「三層構造」。

それぞれを擬人化して説明していく。

 

 

・Webサーバ

まずは女将さんこと「Webサーバ」。

なぜ女将さんかと言うと、こいつが司令塔だから。

クライアントからのリクエストをまず女将さん(Webサーバ)が受け取る。

この女将さんが的確に指示出してあげないと、後に続く職人さん(Appサーバ)や素材屋さん(DBサーバ)が仕事できないってわけ。

どうやらこいつは最強にしないといけなさそうだ。

 

ちなみに「nginx」(nginx - Wikipedia)使う予定。

 

 

・Appサーバ

こいつは職人さん。

女将さん(Webサーバ)から指示を受けてせっせと働くんやな。がんばれ。

 

こいつの役割は、

・セッション管理

・・・セッションIDの発行や管理

 

トランザクション管理

・・・業務上、まとめて確実に実行される一連の処理(トランザクション

ん、なんやそれ....?

 

例えば、ネットで買い物したときのトランザクション

 

・商品在庫を一つ減らす

・クレジットカードの請求処理を行う

 

みたいな。

 

 

・DB接続の管理

・・・DB接続 / 切断

 

DBはドラゴンボールやないで。

データベースや。

情報が表にまとまってるイメージかな。

 

 

職人さんだからもっとやることはいっぱいあるけど代表的なやつをちょこっと紹介。

うん、どうやらこいつも最強に育てなければならないらしい。

 

Ruby使うならUnicorn + Sinatra (またはRuby on Rails)かな。

 

 

 

・DBサーバ

今回初登場の素材屋さんこと「DBサーバ」。

大量の情報を管理してくれる。

CRUD」っていうDBに対する基本操作があって、下の4つがそれ。

 

・生成(Create)

・・・新しい情報をDBに登録する

 

・読み取り(Read)

・・・DBに登録されている情報を読み取る。条件によって合致する情報を抽出する(これが検索処理)

 

・更新(Update)

・・・DBに登録されている情報を更新する。

 

・削除(Delete)

・・・Dbに登録されている情報を削除する。

 

例えば、マサ(以前登場した人物。別の記事でちゃんと紹介しますww)のプロフィールをDBに登録する。

まず、「マサのプロフ」っていう表を用意する。

これが「テーブル」。

 

んで、名前とか誕生日とか身長とか体重とかの各項目があるでしょ。

これが「カラム」。

 

これだとマサの情報だけで一行になっちゃうからアレなんだけどね。

これが「AKB48のメンバー」になると、何行にもなるよね。

この時、一行のまとまった情報に対して「レコード」って言うんや。

 

そしてSQLっていうDB専用言語を使って、必要な情報を取り出すってわけ。

SQLの命令は、

 

・何を

・・・マサの「誕生日」を

 

・どこから

・・・「マサのプロフ」テーブルと「AKB48のメンバー」テーブルから

 

・どのように

・・・誕生日が同じ、という条件で

 

取り出す。

 

ざっとこんな感じ。

これらをAppサーバとDBサーバがSQLを使って情報の受け渡しをしているんや。

 

情報が多くなってくるとこいつも最強にしなければならんな。

 

ちなみに使うとするなら「MySQL」とか「PostgreSQL」かな。

 

 

実際にISUCONで戦うとなると、CPUとメモリから判断してこの3つの内、どいつを最強(チューニング)にしていくかってことになる。

各サーバを1つのノードにまとめて入れるのか、それとも1ノード1サーバにするのか。

それぞれにMAXパフォーマンスを出させてあげて、それでも重くなるようだったらサーバ(ノード)分けてあげるとか。

まぁ色々パターンはあるみたい。

 

一般的な構成としては、WebサーバとAppサーバとDBサーバを1つのサーバ(ノード)にまとめて入れちゃうみたい。

 

ちなみに「オートスケール」っていう、自動でサーバを増やしたり減らしたりすることもできるみたい。

 

「あ、こいつやばいな。サーバ増やして負荷軽くしてやろう」

 

みたいな。

 

 

以上が「Webシステムの三層構成」。

女将さん・職人さん・素材屋さんのどれから最強(チューニング)にしていくのか、作戦会議をしながら進めるみたいです。

 

「プロになるためのWeb技術入門」終わり!!

(ISUCON出場に向けて、本書の全7章のうち5章までを読みました。)

 

 

「プロになるためのWeb技術入門」 ――なぜ、あなたはWebシステムを開発できないのか

「プロになるためのWeb技術入門」 ――なぜ、あなたはWebシステムを開発できないのか

 

 

 

「プロになるためのWeb技術入門」を読んで 〜Cookie〜

今日は「Cookie」について。

なんだか美味しそうだね。

ちなみにぼくはオートミールクッキーが好きですw

 

 

Cookieとは

 

Webブラウザに情報を持たせる技術。

WebアプリケーションとWebブラウザ間で情報を交換できる技術。

 

どーゆーことかと言うと、

ログイン情報とかの来訪履歴って感じかな。

 

 

ブラウザ:「こんちはー。」

サーバ:「いらっしゃいませー。お、初来店やね。じゃあ会員証(Cookie)やるよ。」

ブラウザ:「あざっす!」

 

 

ブラウザ:「やぁ、またきたでー。」

サーバ:「会員証(Cookie)確認おっけー。」

ブラウザ:「お、この前買い悩んでたものまだカゴに残ってるやんけ。」

サーバ:「せやで。おれってええ奴やろ。」

ブラウザ:「あざっす!」

 

 

Cookieはサーバからブラウザに送られる。

各アクションごとに情報が更新されてく。

例えば、

・ログイン時のユーザ情報登録で更新

・何か買ったら更新

みたいな。

 

こうやって毎回同じサイトにきた時にいちいちログイン情報を入力しなくていいわけやな。

うん、便利や〜。

 

でも、そんな美味しくて便利なCookieにも問題点があるんやと。

 

どうやらCookieはテキストファイルとしてPC上に保存されるらしい。

ダイアログをのぞけばそれが見れるんだって。

 

困ったな、どうしようか。

 

 

セッションID

銀行窓口の受付番号的なやつ。

 

「受付番号372番でお待ちのお客様、お手続きが完了いたしましたので窓口までお越しくださいませ。」

 

そう、これこれ。

こうすれば個人名呼ばれなくて済むよね。

 

******************

セッションID:372

名前:マサ

受付:完了

手続き:手続き中

完了:まだ

******************

 

このセッションIDをCookieに入れてサーバとクライアントがやりとりをするんやな。

結局のところ、Cookieを使うことに変わりはないからCookieの情報を分からなくしてやろうって考え方やね。

もちろんセッションIDはただの数字(または文字列)だから誰が見ても分からんというわけ。

 

 

イメージとしては、DBから取ってきた情報を変数に入れるイメージかな?

ここらへんはもうちょっと調べてみよう。

 

ではでは、今日はこの辺で。

 

 

「プロになるためのWeb技術入門」を読んで 〜HTTP〜

先ほどコンサル会社の2dayインターンシップを終えました。

ナメてかかったわけではないですが、予想以上に頭使いました。

ぼくのザコ脳内メモリでは荷が重すぎたみたいですww

 

 

んじゃあ、早速「HTTP」について。

 

HTTPとは通信プロトコルの一つで、「情報の伝達方法」と「情報の意味付け」を規定するものでしたね。

 

では、どうやって情報を届けるのか。

 

IPアドレス

を使うんやと。

192.168.0.1 ←これ

人間世界と同じ、住所ってことですな。

 

このIPアドレスがわかると宛先のホストが特定できて、そいつに情報届けることができるらしい。

その役割は

TCP/IP

っていうプロトコルがやってくれるんやと。

情報をパケットという小さな単位に分割して送受信している。

郵便屋さんみたいなやつやね。

 

ん、待てよ。

URLも住所だよな。

URLとIPアドレス、どっち使えばええねん!

 

 

DNS

Domain Name System

ほうほう、こいつが打ち込んだURLをIPアドレスに変換しているらしい。

 

クライアント:「www.dirty.jpのIPアドレス教えてくれや」

DNSサーバ:「187.149.198.45や。覚えときや。」

 

こんな風に問い合わせることもできるらしい。

 

しかし、ここで終わらないのがインターネットの奥深さ。

 

 

「ポート」

郵便屋さんのTCP/IPは受信した情報がどのようなプロトコルか、どのアプリケーションが処理すべきわからないんだって。(なんだよ、ただ届けるだけかよw)

そこでこの「ポート」、港を使って情報を待つんだと。

Aは第一港、Bは第二港みたいに、その情報がどのプロトコルかを識別しているわけやな。

ちなみにHTTPはポート番号80で、SSHは22らしい。(SSH、22はどこかで使った記憶が....)

 

だから正確な書き方としては

 

www.dirty.jp:80

187.149.198.45:80

 

になるんだけど「:80」は省略されるって。

 

 

最後に

「GET」と「POST」

 

これは情報の渡し方、パラメータの渡し方の違い。

 

ん、「パラメータ」ってなんぞや.....。

 

例えば、

http://www.dirty.jp/unko/brown.php?num1=10&num2=20

がある。(入力欄に10と20を入れている)

 

パラメータはこれで言う、「num1」と「num2」。

 

「10」と「20」は値。

 

「?」以下をクエリ文字列と言って、「パラメータ名=値」の形式で表されている。

 

おっけ、パラメータ分かった!www

 

 

話を戻すと、

http://www.dirty.jp/unko/brown.php?num1=10&num2=20

はGETでの渡し方。

 

POSTはと言うと、

http://www.dirty.jp/unko/brown.php

になる。

 

お、クエリ文字列がないやんけ。

 

なぜか。

 

答えは「セキュリティ」の問題。

アカウント作るときにユーザ情報を入力するでしょ。

それって個人情報やん。

パラメータとしてそれがURLに出てきちゃったらマズいよねって話。

だからGETとPOSTはちゃんと使い分けよう。

 

まとめるとこう。

 

「GETリクエスト」

・メソッド:GETメソッド

・パラメータの格納場所:URL

・セキュリティ:低い(サーバにログが残る)

・パラメータの長さ:制限の可能性あり

・パラメータの保存・再現:しやすい

 

「POSTリクエスト」

・メソッド:POSTメソッド

・パラメータの格納場所:メッセージ・ボディ

・セキュリティ:比較的高い(サーバにログが残らないことが多い)

・パラメータの長さ:制限なし

・パラメータの保存・再現:しにくい

 

 

ざっとこんな感じ。

 

 

 

ではでは、今日はこの辺で。

 

 

 

 

「プロになるためのWeb技術入門」を読んで 〜URL〜

 

前回記事の最後にURLの話をしたけど疲れちゃったので続きを。

 

matsuda-juri.hatenablog.com

 

まずはURLの構成から。

 

例えば

http:// www.dirty.jp/unko/index.html

ってのがあるとする。(汚くてすいません。)

 

「えいちてぃーてぃーぴーころんすらすら」のアレ。

これは大きく3つに分けられる。

 

・「http:」 → スキーム

リソースの取得方法を表している。

 

 

・「www.dirty.jp」 → ホスト名

リソースが存在するホストコンピュータ名を指している。

んで、このホスト名はまた2つに分けることができて、

 

  「www」 → ローカル名

  「dirty.jp」 → 親ドメイン

になると。

 

"jp" → 日本の

"dirty" → dirtyという組織の

"www" → WWWサーバというコンピュータ

 

って意味らしい。

 

 

 ・「unko/index.html」 → パス名

 ホスト名で指定されたコンピュータ上のリソースの位置を示す。

上で言うと、「unko」ディレクトリの下にあるindex.htmlというファイルを示しているんやと。

 

 

そうか、URLっちゅーのは

ドメイン → コンピュータ → ディレクトリ → ファイル名

で指定してるのか。

 

 

......ん、待てよ。

「http」ってなんぞや。

 

 

 

ざっくり言うと、「http」はお約束ごと。

サーバとクライアントが通信を行うときに、どうやって情報のやりとりするかって取り決めなんだと。

 

クライアント:「HTMLが欲しいんやけど、どうやってやりとりしようか?」

サーバ:「そうだね。HTTPでよくね。」

クライアント:「おっけ、じゃあそれで。」

 

みたいな感じかな。

この取り決めを通信プロトコルって言うそうな。

 

 

そういや昔「狼煙」ってあったよね。

遠くの人に情報を伝える手段の、あの煙や。 

 

狼煙は、

・煙を使って合図を伝えること

・敵の襲来を示すこと

・狼煙の煙を見たら、自分たちも狼煙を上げてさらに周囲の人に伝えること

 

これがプロトコル、狼煙の取り決めやったんやな。

やはり先人たちはすごい。

便利な世の中になったもんだ今は。

 

 

ではでは、今日はこの辺で。