ストックドッグ

KatoTakahiro。金融系の会社で働くSEが株やPython、その他諸々について書いています。サービスも運営してます→http://fmbrain.work

Ubuntuからconoha（VPS）にSSH接続してみる

Ubuntu cohoha

苦労したよ

SSH接続、けっこう詰まったので自分なりにまとめておきます。

あと、conohaのサイトは案外サラッとしか書いていないので、自分なりにではありますが設定を行う理由なんかも書いて詳しめの記事にしています。

間違っていたらすみません。笑

SSH接続をする理由

conohaはサイト上からコンソールを開けるので、とても便利です。

しかし、いちいちconohaのサイトに行ってコンソールを開いて...ってやるのは面倒なので、自分のPC（クライアント）からconohaのVPSをリモート操作しましょう。

っていう導入的な部分は他のサイトにたくさん書いてあるので、さっさと本題に行きます。

まずはパスワード認証でSSH接続

SSH接続には2つの接続方法があります。

  • パスワード認証方式
  • 公開鍵認証方式

パスワード認証方式は、セキュリティの面から推奨されていません。（後に後述）

まずはパスワード認証によるSSH接続を行い、後でパスワード認証から公開鍵認証に変更します。


まずはrootでVPSにログインします。

そして、sshd_configを設定を変更します。

sshd_configにssh接続に関する設定が記述してあります。

ここで2つの設定を変更します。

vi /etc/ssh/sshd_config
  • PasswordAuthentication no → yes
  • ChallengeResponseAuthentication no → yes

この2つをnoからyesに変更します。

私の乏しい知識でこの2つの設定の意味を説明すると、パスワード認証を許可するか否かです。

PasswordAuthenticationはパスワード認証の許可、ChallengeResponseAuthenticationはパスワードを送った際にログイン成功か失敗かを示すためのものです。

基本的にサーバーは、ブルートフォースアタック（何通りものパスワードを送りつけてログインを試みる力技攻撃）を避けるためにパスワード認証は許可しません。

そのため、これら2つはデフォルトでnoになっています。

SSH接続を行うために一時的にyesにするだけなので、後でnoに変更します。

2つともnoに変更したら。

service sshd restart

でsshd_configの変更を反映。


これでクライアントPCからSSH接続を試みると成功するはずです。

ssh root@157.7*******

公開鍵方式でSSH接続

VPS側のホームディレクトリにいきます。

#cdでホームディレクトリに移動
cd

このホームディレクトリに公開鍵を入れるフォルダを作ります。

たしかubuntuにはデフォルトでなかったで、私は自分で作ったのですが、すでにあれば作る必要はありません。

#公開鍵をいれるフォルダがあるかを確認
#オプション-aで隠しファイルも表示される
ls -a

そこに.sshというフォルダがなければ。

mkdir .ssh

次に、この.sshフォルダに書き込み、読み込み、実行の権限を与えます。

chmod 700 /root/.ssh/

ここで先ほどいじったsshd_configをもう一度いじり直しにいきます。

vi /etc/ssh/sshd_config

設定を変更するのは公開鍵認証を許可するためです。

#RSA鍵を許可
RSAAuthentication yes

#公開鍵認証を許可
PubkeyAuthentication yes

#公開鍵の場所をここで明示
AuthorizedKeysFile      .ssh/authorized_keys


以上の作業が終わったら、ここからクライアントPCに戻ります。

#クライアントPCの.sshフォルダに移ります
ls -a
cd .ssh

ここで秘密鍵と公開鍵を生成します。

ssh-keygen -t rsa -b 2048

ssh-keygenはSSHで利用する認証用の鍵を生成・管理・変換するコマンドです。

鍵のタイプはRSA、2048bitの鍵を生成します。

生成時にパスフレーズを要求されますが、全てデフォルトでかまわないので、全部Enterで問題ないと思います。

生成されるid_rsaが秘密鍵、これは絶対にばらしちゃいけないので大切にPCに保管しておきます。

id_rsa.pubは公開鍵で、こちらをVPS側にアップロードします。

そして、公開鍵に読み書きの権限を付与します。

chmod 600 ~/.ssh/id_rsa.pub

そして、VPS側に送ります。

scp id_rsa.pub root@157.7*******:/root/.ssh/authorized_keys

scpはリモートとクライアント間でファイルをコピーするためのコマンドです。

今回はid_rsa.pubをauthorized_keysという名前に変えてVPSにコピーしています。

authorized_keysというファイル名は伝統のようです。


これで公開鍵認証方式でのSSH接続が可能になるはずです。

ssh root@157.7*******

パスワードなしで接続されれば、成功です。

逆にパスワードを要求されれば、失敗です。

root以外でのユーザーでSSH接続を行う

rootで接続を許可してしまうのは、なかなかまずいです。

もし、サーバーを乗っ取られた場合rootだと何でもできてしまうからです。

なので、SSH接続はroot以外のユーザーで行う必要があります。

VPS側でユーザーを追加し、これまでと同じ手順で公開鍵認証方式でのSSH接続を設定します。

ユーザーの追加。

#ユーザー追加
adduser user_name

#追加したユーザーがsudoコマンドを使えるようにする
gpasswd -a user_name sudo

ここまでやったら、あとはrootでの手順と同じなので省略。

ただ、公開鍵を送るときに気をつけたいのは。

scp id_rsa.pub root@157.7*******:~/.ssh/authorized_keys

ではなく、

scp id_rsa.pub root@157.7*******:/home/user_name/.ssh/authorized_keys

と、user_nameのフォルダに送ることをしっかりと記述しないといけません。

前者だとrootのほうのフォルダに送られてしまいます。

私はこのミスに気づくのにかなり時間を費やしました...笑

最後にrootでのログインとパスワード認証を禁止する

#パスワード認証の禁止
PasswordAuthentication no
ChallengeResponseAuthentication no

#rootでのログイン禁止
PermitRootLogin no

設定し終わったら、

service sshd restart

これで設定が反映されたはず。

rootでのログインはできなくなっています。

まとめ

conohaはさくらVPSより安くて良いのですが、さくらVPSと比べると情報量はどうしても劣りますね。

とくに私のようにはじめてVPSを使用する人からすると、エラーでたときにかなり困りました。

日本のサービスなので海外サイトにものっていませんし。

なので、私のようなVPS初心者のかたがconohaを使った時のためにけっこう詳しめに書きました。

（エラーがでまくったので、その都度調べるたびに勝手に詳しくなってしまった感はあるが）

誰かの助けになれば幸いですね。

以上終わり！

seleniumの環境構築と簡単な使い方

Python

今は日曜日の夜2時

早く寝ないと！！

明日は仕事なんです。

急いで書くのでぶっきらぼうな今日は文章になるかもです。

何とかブログだけ書いてさっさと寝ます。

環境構築

pipでインストール可能です。

pip install selenium

seleniumはAPIを通じてブラウザを使用するため、seleniumとは別にブラウザ用のドライバーをインストールする必要があります。

sites.google.com

Safari、Firefox、Chrome、Edge、どれでも好きなブラウザのドライバーの圧縮ファイルをHPからダウンロードでき、私はChromeを選択しました。

ダウンロードした圧縮ファイルを解凍するとChromedriverというファイルが現れます。

これをseleniumを使用するファイルと同じフォルダに入れておきます。


公式HPにはPATHを通すと書いてあったが、そこは本人の自由。

私は面倒だったので、そのままコードの中にChromedriverの位置を書きました。


ここらへんの環境構築にちょっと苦労しました。

Youtubeで「YUI」と検索する操作をseleniumを使ってやってみる

#unittestは単体テスト用のライブラリ。
#動作の開始から終了までの時間を計測してくれるので、なんとなく使用。
import unittest

from selenium import webdriver
from selenium.webdriver.common.keys import Keys


class PythonOrgSearch(unittest.TestCase):

	def setUp(self):
		#pwdでカレントディレクトリを確認。
		#カレントディレクトリの場所をそのまま記述。
		#seleniumを実行するファイルとChromedriverを同じ場所に格納が楽。
		self.driver = webdriver.Chrome("/home/ubuntu/serv/robo/chromedriver")


	def test_serch_in_python_org(self):
		driver = self.driver
		#youtubeのURL
		#driverの中にはサイトの構造がHTMLとして格納されている。
		driver.get("https://www.youtube.com/")

		#youtubeの検索バーはid="masthead-search-term"
		#find_element_by_idで検索バーのidを取得してくる
		elem = driver.find_element_by_id("masthead-search-term")

		#yuiと検索
		elem.send_keys("yui", Keys.RETURN)

	def tearDown(self):
		self.driver.close()


if __name__ == "__main__":
    unittest.main()


ちなみに、youtubeのサイト構造の画像。
id="masthead-search-term"が検索バーであることがわかります。

f:id:doz13189:20170424023003p:plain

クリックもできるselenium

クリックを自動で行いときは.click()で可能。

方法はだいたいさっきと同じで、HTMLからクリックしたい要素のidを探して.click()をつけたします。

driver.find_element_by_id("about").click()

公式サイトを見るとドラッグ・アンド・ドロップもできるみたいだが、どの場面でドラッグ・アンド・ドロップを使うのかは私には思いつかない...

id要素以外の見つけ方

  • find_element_by_id
  • find_element_by_name
  • find_element_by_xpath
  • find_element_by_link_text
  • find_element_by_partial_link_text
  • find_element_by_tag_name
  • find_element_by_class_name
  • find_element_by_css_selector

案外たくさんある...

個人的にはclass_nameとidがあれば90%の作業はすむと思っています。

けっこう簡単だったselenium

思いの外使いやすかったです。

使い方自体もシンプル。

そして、汎用性抜群。

もうしばらく触ってみます。

隠しファイルの見方

Ubuntu

ドット（.）から始まるファイルは通常、lsコマンドをうっても表示することは出来ません。

ls

ドットから始まるファイルは隠しファイルと呼ばれ、例えば環境変数を格納するために使ったりする.bashrcなどがあります。

これらを表示するにはlsコマンドにオプションをつけて、うつことで隠しファイルを表示することが出来ます。

ls -la

以上、終わり

herokuにルート権限はあるのか？

heroku

4月からはもっぱらherokuにつきっきりです。

ようやくherokuの全貌をつかめてきた感覚があり、前は読んでもわからなかった記事も少しづつではありますが、理解できるようになってきたところです。

今までローカルで動かしていたプログラムを自動プログラムに書き換えて、Webアプリで提供するという夢があと一歩のところまで来ました。

長かったです。

4月に入社して飲み会ラッシュの中、同期にはちょっとづつ飲み会苦手キャラを浸透させつつ、飲み会を断りやすい雰囲気を作って、5時に帰れる日は直帰してプログラムを書いて...

苦労に苦労を重ね、そして、大きな問題が発生しました。

まずはじめにroot権限とは？

ubuntuユーザはpip install ライブラリ を行う際、たいていsudoをつけます。

sudoというのはルート権限であることの宣言であり、sudoをつけることでファイルの書き込み・変更等を許可することになります。

ライブラリによってはファイルの書き換えを行う必要があるので、sudoをつけなければ、ファイルの書き込みができません的なエラーを発生させる要因になります。

たしか、windowsでは、コマンドプロンプト自体を起動する際にroot権限で起動するか否かを選択したはずです。

ここらへんの違いは設計思想の違いなんですかね。

herokuにroot権限はあるのか？

herokuはIaas系のサービスで、のせるOSは自由に選べます。（toolbeltという形で選択が可能です）

私はherokuにはUbuntuの環境を構築したのですが、なぜかheroku上でsudoコマンドが使用できません。


これが何を意味するかというと、ファイルを書き換えるライブラリがインストールできない、ということです。


これは詰みです。

本来、herokuからインストールできないライブラリ等はbuildpacksによってソースから直接インストールすれば良いのですが（私の解釈が間違ってなければ）、

今回はインストールできないわけではなくて、heroku上で動かすにはファイルを書き換える必要がある、ということなのでbuildpacksでは解決できません。


3日かけて（貴重な土日と5時帰りの月曜の夜）色々とgoogleで解決方法を探しまわったのですが、無理でした。

普通に考えてIaasでroot権限がないって考えにくいなぁと思いつつ、ただ自分では解決できないので諦めることにしました。

ただ一つ、良いことがあるとすれば、このエラーを餌に同期の中からプログラミング好きな人をたくさん見つけれたことです。

「プログラミング得意！？このエラーでてるねんけど、わかる？教えて！」みたいなノリで声をかけまくりました。

違うサービスを使しかないか...

仕方がないです。ドキュメントたくさん読んで、色々できるなぁなんて妄想していましたが...

プログラミングをはじめてそろそろ1年たつのですが、ガチで解決できないエラーに出会ったのはこれがはじめてでした。

この出会い一生忘れないと思います。


次のサービスの候補としては、AWS、Googleのやつ、さくらのVPS、conoho、このあたりです。

conohoは全く存在を知らなくて、同期の人に教えてもらいました。

今日の夜あたりからちょっとづつ調べながら次の移転先を探してみます。

以上、終わり。

herokuのタイムゾーンを変更したらAPSchedulerが動いた話

heroku

APSchedulerがピクリともしない問題発生

APSchedulerをcron式タイムスケジュールで0:20に命令を実行したいのですが、なぜか0:20になってもピクリともしませんでした。

from apscheduler.schedulers.blocking import BlockingScheduler

sched = BlockingScheduler()

#0:20
@sched.scheduled_job('cron', hour=0, minute=20)
def scheduled_job():
    print('This job is run every weekday at 0:20.')

sched.start()

時間設定の仕方はhour=0、minute=20で0:20を指すはずだが...

APChedulerをcron形式で動かすドキュメントを読んだので、きっと間違いはないはず。

apscheduler.triggers.cron — APScheduler 3.3.1.post4 documentation

だが、動かぬ。

タイムゾーンを変更していなかった

herokuのログを見るたびにいつも時間がずれてるなぁ、これどこの時間なんや、と思いつつ放置していたのですが、それが原因でした。

タイムゾーンがUTCでした。

ということで。

herokuのタイムゾーンをJSTに変更

まず、herokuの現在のタイムゾーンを念の為確認。

#heroku上でbashを起動してから。
heroku run bash

#タイムゾーンを確認
date

UTCだったので、タイムゾーンをJSTに変更。

heroku config:add TZ=Asia/Tokyo

TZ=Asia/Tokyoという環境変数を追加して、設定を変更。

無事解決しました

最近は株価の分析には時間が割けてなくて、heroku上でシステムを動かすことにばかり時間を費やしています。

あまり楽しくはありませんが、これから自分一人でシステムを作っていこうと思うと避けて通れない道だと思っています。

なので、焦らず地道にドキュメントを読みながら作業を進めています。

herokuでのスケジュール管理にAPSchedulerを使ってみる

Ubuntu Python

目次

herokuで定期的にファイルを実行したいとき何を使っていますか？

cron?

heroku scheduler?

APScheduler?

cron...?

DBの更新、データの取得、バックアップの保存などのスケジュールの管理はモダンなWebアプリには必須機能です。

ubuntuのデフォルトでインストールされているcronはあらゆるスケジューリングが可能で、上記のほとんどのことはcronによって達成することが出来ます。

ですが、cronはサーバー上で動作することもあり、Webアプリのテストをローカル環境で行うことを考えると、もっと高いレイヤーのアプリケーションのインスタンスで動作するほうが勝手がいいです。

heroku scheduler...?

herokuにはスケジュール管理のためのファンタスティックなアドオンが用意されています。

このheroku schedulerはシンプルなタスクを10分、1時間、一日、複数の間隔での実行が可能です。

しかし、5分や37分など中途半端な時間での実行は難しいです。

cronよりもheroku schedulerよりAPSchedulerが良い

アプリケーションのインスタンスで動作し、かつ、中途半端な時間でも簡単にスケジュールの管理が可能なのが、APSchedulerです。

これはPython製のライブラリなので、私のようにwebアプリを全てpythonで完結させたい人たちにはもってこいです。

heroku上でAPSchedulerを使ってみる

ということで、1分おきに現在時刻をDBにインサートするプログラムを書いてみます。

最終的な出力はこうなります。

herokuのログを見ると、1分おきにDBを更新していることがわかります。

f:id:doz13189:20170410001021p:plain

用意するもの

herokuでアプリを運用するために必要なファイルは以下です。

#適当に用意してください
runtime.txt
requirements.txt

#以下は今から作成します
Procfile
gettime.py
time.db
timeclock.py

スタート。

#screamtimeという名前のアプリを作ります
heroku create screamtime

次に、gettime.pyを作成します。

import sqlite3
import pandas as pd
import datetime


#現在時刻を取得する
now = datetime.datetime.today()
hour = now.hour
minute = now.minute

#DataFrame形式にぶち込む
#普通はSQL文書いてインサートすると思いますが、
#私がDataFrame形式に慣れているので、こちらを使用していますが、各自なれた方法でお願いします
time_df = pd.DataFrame({"Hour" : [hour],　"Minute" : [minute]})


#db作成
dbname = "time.db"

#dbコネクト
conn = sqlite3.connect(dbname)
c = conn.cursor()

#dbのnameをtime_dfとし、読み込んだcsvファイルをsqlに書き込む
#if_existsでもしすでにtime_dfが存在していても、置き換えるように指示
time_df.to_sql("times", conn, if_exists="replace")

#作成したdbを見てみる
select_sql = 'select * from times'
for row in c.execute(select_sql):
    print(row)

conn.close()

これをgettime.pyという名前で保存します。

次は、今作成したgettime.pyをAPSchedulerで定期的に実行させるコードを書きます。

from apscheduler.schedulers.blocking import BlockingScheduler
import os

sched = BlockingScheduler()

#間隔は1分ごとにしています
#minutesではなくてhourに変更したら、時間での指定も可能です
@sched.scheduled_job('interval', minutes=1)
def timed_job():
	print("Let's start")
	os.system("python gettime.py")


sched.start()

これをtimeclock.pyという名前で保存します。


最後にProcfileを作成します。

clock: python timeclock.py

これで、herokuにclockのファイルであるということを宣言します。

ファイルが全て揃ったので、あとはherokuに上げるだけです。

念の為、herokuに上げるまでのgitでの手順を載せておきます。

git init
git add .
git commit -m "first commit"
git push heroku master

エラーなく行けば、これでherokuには「1分おきに現在時刻をDBにインサートするプログラム」がアップロードされました。

以下でherokuにclockをスケールします。

heroku ps:scale clock=1

上手くスケールされたことを確認して。

heroku ps
|<

数分待ってからherokuのログを見てみます。

>||
heroku logs

f:id:doz13189:20170410001021p:plain

以上で「1分おきに現在時刻をDBにインサートするプログラム」が完成しました。

まとめ

APSchedulerはとても簡単にスケジュールの管理が行うことができます。

コードもpythonで書くことができるので、使い勝手がとても良いです。

cronよりもheroku schedulerよりもAPSchedulerが良いんじゃあないでしょうか！？

参考

devcenter.heroku.com

herokuのworker dynoとweb dynoの違いって何?

Ubuntu

目次

dyno？

herokuでは、プロセスの処理はdynoによって行われます。

プロセスの処理とはHTTPのリクエストやレスポンス、バックグラウンド処理などです。

dynoは3種類あり、処理をするプロセスの種類によって使い分けられます。

  • web dyno
  • worker dyno
  • one-off dyno


herokuを勉強していて、dynoはheroku内の独特の単位で一番はじめにつまづいたのでまとめておきます。

web dyno

HTTPのリクエスト・レスポンスを処理します。

ユーザーからのリクエストはweb dynoが処理するので、webアプリが行う処理の大半はweb dynoによって行われています。

worker dyno

バックグラウンド処理を行います。（ほぼweb dyno以外の処理）

バックグラウンド処理とは、例えばAPIsからのデータ取得やRSSフィードの読み込み、画像のリサイズ、S3へのデータ送信などが当てはまります。

one-off dyno

一時的な処理を行うためのdyno。

heroku run

などのherokuコマンドを実行したときに使用されるdynoです。

ログ

これらdynoの動作状況はログを見ることによって確認できます。

#ログの確認
heroku logs -t

#見たい行数を指定する（最大1500行まで）
heroku logs -n 200

Control+Cでログの出力を中止できます。

ログは直近の1500行のみしか表示されず、ログの保存を行う場合はアドオンを追加します。

使用中のdynoを確認する

heroku ps

このコマンドで現在、使用しているdynoを確認することができます。

まとめ

worker dynoとweb dynoの違いは、まとめると処理するプロセスの違い、ということになります。

Webアプリによって必要な処理は違ってくるので、アクセス数がひたすら多いWebアプリはweb dynoを増やしたり（＝スケーリング）、バックグラウンドでの処理が多いならworker dynoを増やしたりと適宜変更しながら運用していきたいですね。