Windows 10からRaspberry PiにSSH接続してみる(公開鍵認証)
はじめに
Raspberry Piを操作するのに、ディスプレイをつないでいたら面倒です。そこで、SSH接続により他のPCからRaspberry Piに接続する方法をメモしておきたいと思います。また、よりセキュアな通信を行うために、BASIC認証ではなく、公開鍵認証にて接続を行います。
1. SSHの設定(Raspberry Pi側)
sudo touch /boot/ssh
次に、[設定] -> [Raspberry Piの設定]からSSHを有効
にしておきます。
リブート後、以下のような警告メッセージが出る場合、パスワードが初期値になっているので、変更しておきましょう。
ちなみに、デフォルトでは以下のUserとPasswordになっています。
User | Password |
---|---|
pi | raspberry |
[設定] -> [Raspberry Piの設定]からパスワードの変更を行えます。
以上でRaspberry Pi側の設定は終わりです。
2. Windows 10からRaspberry PiにSSH接続する(Windows 10側)
今回は、WinSCPを使って接続してみたいと思います。 WinSCPをインストールしていない場合は、以下からダウンロード&インストール。
ホスト名にRaspberry Pi側のIPアドレス、ユーザ名とパスワードを設定し、ログインボタンをクリックします。
すると、以下のように接続できていると思います。
以上で、Windows 10側からのBASIC認証によるSSH接続は完了です。
3. 公開鍵認証でSSH接続
BASIC認証だとセキュアとは言えないので、今回は公開鍵認証でSSH接続する方法についても言及します。
Windows 10側
まず、Windows 10側で公開鍵と秘密鍵のペアを作ります。
OpenSSHを使おうと思うので、Gitがインストールされていることを前提としています。 Gitをインストールしていない場合は、以下からダウンロード&インストール。
Git Bashから、以下のコマンドを実行します。 メールアドレスについては任意の値でOKです。
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
保存先やパスワードの入力を求められますが、何も入力せずにEnterします。
すると、C:\Users\ユーザ名\.ssh
直下に
* id_sra (秘密鍵)
* id_rsa.pub (公開鍵)
が作成されます。
WinSCPで公開鍵であるid_rsa.pub
をRaspberry Pi側に転送しておきます。
Raspberry Pi側
先ほど転送した公開鍵をRaspberry Pi側に登録します。
# ホームディレクトリへ移動 cd /home/pi # 公開鍵をRaspberry Pi側に登録 mkdir .ssh cat id_rsa.pub >> .ssh/authorized_keys # 権限を設定 chmod 700 .ssh chmod 600 .ssh/authorized_keys
SSHの設定ファイルを開きたいのですが、nanoやVimでもいいのですが、編集しやすいVSCodeを使います。まず、VSCodeをインストールしておきます。
# VSCodeのインストール wget -O - https://code.headmelted.com/installers/apt.sh | sudo bash # VSCodeの実行 code-oss
次に、SSH設定ファイルを開きます。
# 一時的に権限を変更 sudo chmod 666 /etc/ssh/sshd_config # VSCodeで開く code-oss /etc/ssh/sshd_config
(1) 公開鍵認証の設定
以下の2つについて、コメントアウトしているのは解除し、PubKeyAuthentication
をyes
に書き換えます。
PubkeyAuthentication yes
# Expect .ssh/authorized_keys2 to be disregarded by default in future. AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
(2) BASIC認証をできないようにする
コメントアウトしているのは解除し、PasswordAuthentication
をno
に書き換えます。
# To disable tunneled clear text passwords, change to no here! PasswordAuthentication no
(3) Rootログインをできないようにする
コメントアウトしているのは解除し、PermitRootLogin
をno
に書き換えます。
PermitRootLogin no
SSHを再起動し、上記の設定を反映させます。
# 権限をもとに戻す sudo chmod 644 /etc/ssh/sshd_config # SSHの再起動 sudo /etc/init.d/ssh restart
Raspberry Pi側の作業を以上で終了です。
最後に、WinSCPで秘密鍵を設定し、Raspberry Piに接続できるかどうか確認して見ましょう。 設定をクリックします。
SSHの認証から、秘密鍵を設定します。ppkしか対応していないと言われるので、素直にppkファイルに変換します。
設定を保存し、ログインします。公開鍵認証がうまく行っていれば、以下のようにSSH接続できているはずです。
参考
Raspberry Piに公開鍵認証を使ってssh接続する
https://tool-lab.com/2013/11/raspi-key-authentication-over-ssh/
[wip] Raspberry Piのセキュリティを高めてみた
https://qiita.com/yyano/items/126cff2e3c49b0006c43
Windows10パソコン上にGitサーバを立ててみた - LinuxサーバがないけどGitサーバを運用したい場合の対処法
はじめに
会社や研究室でGitを使ったバージョン管理システムを構築したいというニーズが少なからずあると思います。言うまでもなく、ソースコードやそれに付随する書類を管理する上で、手作業でそれを行うのは非常に非効率だからです。
今回は、Linuxサーバを持っておらず、Windows OSの入ったパソコンしか使えない場合を想定して、Windows10パソコン上にGitサーバをたてる方法について説明します。
WindowsパソコンにGitサーバを立てることはまずやらないためか、ネット上での情報が少なく、公開されている情報も断片的だと感じたので、今回私なりにまとめてみることにしました。
実行環境
- Gitサーバ (Windows10 Pro)
- Gitクライアント (Windows10 Pro)
Gitのインストール(サーバ・クライアント共通)
サーバ(Windows10)とクライアント側(Windows)の両方の環境にGitをインストールします。
まず、以下のGitのサイトからGitのインストーラをダウンロードしてきます。
https://git-scm.com/
デフォルトのままで「Next」をクリックします。
Gitで使うデフォルトのテキストエディタを選択します。Windows環境なので、無難にVisual Studio Codeを選択しておきます(事前にVSCodeをインストールしておく必要があるかもしれません)。
GitコマンドをGit BashだけでなくWindowsのコマンドプロンプトでも利用できるようにするか聞かれます。今回は、コマンドプロンプトでも利用できるように、真ん中のUse Git from the Windows Command Prompt
を選択しました。
HTTPSによる転送をどの方法で行うか聞かれます。今回は、OpenSSLを使うことにし、Use the OpenSSL library
を選択しました。
コミット後、ソースコードをUnixの改行コードに変換するかどうか聞かれます。今回は、Windowsで利用することを想定しているので、Checkout as-is, commit as-is
を選択しました。
ただし、MacOSやLinux OSでも利用することを想定している場合は、Checkout as-is, commit Unix-style line endings
にしておき、Unixの改行コードに統一しておくのが良いと思います。
デフォルトのままで「Next」をクリックします。
デフォルトのままで「Install」をクリックします。
以上でインストールは完了です。
クライアント側の設定
まずは、クライアント側で作業を行います。
1. Gitのグローバル設定
Git Bashもしくはコマンドプロンプトを開き、以下のコマンドを実行します。メールアドレスとユーザ名については任意の値を設定してください。
# ユーザ設定 git config --global user.email "administrator@example.com" git config --global user.name "Administrator" # 日本語名を表示するための設定 git config --global core.quotepath false # Windows から git プロトコルで push するとハングアップするのを防止 git config --global sendpack.sideband false
2. SSHキーの用意
今回はGitプロトコルによる通信ではなく、SSHによる通信方法を使います。理由は、Gitプロトコルでの通信だと専用のポート (9418)を使っての通信になり、環境によっては ウイルス対策ソフトのファイアウォールに引っかかるためです。また、Gitプロトコルの場合、Windows環境ではリポジトリのクローン時にエラー(Index-pack failed
)が発生することがあると確認しています。
Gitサーバの通信プロトコルについての詳細は以下を参照のこと。
https://git-scm.com/book/ja/v1/Git-サーバー-プロトコル
クライアント側でSSHキー(公開鍵と秘密鍵)を作成しておきます。-C
オプションで指定しているメールアドレスは任意のものを設定してください。
以下ではGit Bashで実行した際のコマンドを示しました。以下のssh-keygen
コマンドを実行します。
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
実行すると、id_rsa
とid_rsa.pub
という2つのファイルが生成されているはずです。
このうち、公開鍵であるid_rsa.pub
は、サーバ側にわたす必要があります。
サーバ側の設定
ここからはサーバ側の操作になります。
1. Gitのグローバル設定
クライアント側のときと同様に、Git Bashもしくはコマンドプロンプトを開き、以下のコマンドを実行します。メールアドレスとユーザ名については任意の値を設定してください。
# ユーザ設定 git config --global user.email "administrator@example.com" git config --global user.name "Administrator" # 日本語名を表示するための設定 git config --global core.quotepath false # Windows から git プロトコルで push するとハングアップするのを防止 git config --global sendpack.sideband false
2. リポジトリを作成する
以下の場所(もちろん、任意の場所で構いません)に、リモートレポジトリを作成していきます。
フォルダの種類 | サンプルパス |
---|---|
ベースフォルダ | C:\repos |
リモートリポジトリ | C:\repos\sample.git |
以下では、Git Bashでの操作を示しました。Cドライブの直下にレポジトリ用のフォルダを用意します。
mkdir /c/repos mkdir /c/repos/sample.git
ベアリポジトリ(作業ディレクトリを持たないリポジトリ)を作成します。
# リポジトリの初期化 cd /c/repos/sample.git git init --bare --shared # Gitプロトコル時に共有レポジトリとして認識させる touch git-daemon-export-ok
ベアリポジトリについては以下を参照のこと。
ベアリポジトリとノンベアリポジトリ:理論編〜GitでWordpressのテーマを管理
http://www.nekotricolor.com/entry/theory-of-bare-and-non-bare-repository-manage-wordpress-themes-with-git
3. SSH接続
SSHサーバを立ち上げます。まず、管理者としてGit Bash
を実行します。
GitをインストールしたフォルダにSSHキーを作っていきます。Gitインストール直後は以下のようなファイル構成になっているはずです。
C:Program Files\Git\etc\ssh
パスフレーズは入力せずにEnterを押して、SSHキーを作っていきます。
cd /c/'Program Files'/Git/etc/ssh ssh-keygen -t rsa -f ssh_host_rsa_key ssh-keygen -t ecdsa -f ssh_host_ecdsa_key ssh-keygen -t ed25519 -f ssh_host_ed25519_key
作成すると、Git/etc/ssh
フォルダ内は以下のようになります。
続いて、sshd.exe
を実行して、SSHサーバを立ち上げます。
/usr/bin/sshd.exe
ファイアウォールの設定を聞かれるので、「アクセスを許可する」をクリックします。
タスクマネージャーで確認すると、sshd.exe
が起動していることが確認できると思います。
最後に、クライアント側で用意した公開鍵id_rsa
をサーバ側に登録しておきます。
C:/Users/ユーザ名/.ssh
フォルダの直下にauthorized_keys
というファイルを作成します。
ファイルをテキストエディタなどで開き、クライアント側で用意した公開鍵の内容をコピペします。
4. 外部接続を行うGit Daemonの起動(SSH接続では必要ない)
Gitプロトコルで通信を行う場合は、以下のコマンドでGitサーバを立ち上げておく必要があります。
# git daemon --verbose --export-all --enable=receive-pack --base-path=/c/repos/ git daemon --verbose --reuseaddr --export-all --enable=receive-pack --enable=upload-pack --base-path=/c/repos/
デフォルトは読み取り専用になっています。つまり、git clone
、git fetch
、git pull
はできるけど、git push
はできません。
--export-all
をつけてリモートレポジトリにプッシュできるようにしておくように設定します。
また、--enable=receive-pack
をつけて、認証を受けていないanonymousユーザもプッシュできるようにします。
先ほどのコマンドを実行すると、ファイアウォールの確認画面が出てくるので、「アクセスを許可する」をクリックします。
クライアント側の設定
最後に、クライアント側でGitリポジトリのクローンの作成とGitリポジトリへのプッシュができるか確認します。
1. クローンの作成
ipconfig
であらかじめIPアドレスを確認しておきます。
以下では、IPアドレスが192.168.86.21
、サーバ側のGitのリモートレポジトリがC:/repos/sample.git
だった場合の例を示しました。
コマンドプロンプトで以下のコマンドを実行しました。
git clone ssh://192.168.86.21/c/repos/sample.git
2. SourceTreeで管理する場合
コマンド操作でGitによるバージョン管理をしても良いですが、GUIを使うともっと便利です。今回はSourceTreeを使った例を示します。
まず、クライアント側で用意した秘密鍵id_rsa
をSourceTreeに登録しておきます。[ツール] -> [オプション]からSSHキーを設定します。SSHクライアントにはOpenSSH
を選択します。
3. SourceTreeでのGitリポジトリのクローン
SourceTree上でGitリポジトリのクローンを作成します。まず、新しいタブから「Clone」を選択し、クローンのURLを指定します。上記の例だと、ssh://192.168.86.21/c/repos/sample.git
になります。
「クローン」をクリックすると、対象のGitリポジトリのクローンを作成できます。
3. SourceTreeでコミットとプッシュを実行
GitリポジトリにREADME.md
ファイルを追加してコミットを行います。
続いて、プッシュを行います。プッシュをクリックすると、以下の画面が表示されるので、masterブランチを選択し、「プッシュ」をクリックします。
SSH接続がサーバ・クライアント間でできていれば、以下のようにプッシュが完了します。
トラブルシューティング
SourceTreeからのプッシュがいつまで立っても終わらない…
以下の設定を行うことで解決。
git config --global sendpack.sideband false
SourceTreeのPushが終わらない(社内ローカル +Windows環境)
https://teratail.com/questions/110660
Gitサーバに繋がらない…
Gitがクローンできない理由として、Windowsのユーザ認証が邪魔をしている可能性があります。
IPアドレスの前にログインユーザ名(サーバ側)、IPアドレスの後ろにSSHのポート番号を指定して実行するとうまくいきます。
git clone ssh://imama@192.168.86.31:22/c/repos/sample.git
参考
Windows Server上にGitリモートリポジトリを導入する手順書
https://qiita.com/nipoko/items/6e81a6021358ff8c03e9
WindowsのGitサーバ(リモートリポジトリ)構築メモ
http://nosource.blog35.fc2.com/blog-entry-142.html
gitで日本語ファイル名を表示する方法
https://qiita.com/kozo/items/08dc2b86ae3ba3f282c3
How to fix Windows 7 64 Bit git push msysgit hang up Problem
https://weberde.wordpress.com/2013/02/06/how-to-fix-windows-7-64-bit-git-push-msysgit-hang-up-problem/
Ubuntu 18.04 LTSにDockerを使ってGitLabとMattermostを導入してみた
はじめに
Gitのバージョン管理システムとしてGitHub、継続的インテグレーションツールとしてCircleCIやTravisCI、開発者向けのコミュニケーションツールとしてSlackといったクラウドサービス(SaaS)が注目を集めています(というより、昨今では当たり前に使われているツールかも)。
しかし、会社によってはクラウドはNGでオンプレミスである必要があったり、予算的な問題があったりとなかなか導入できない事情があるかと思います。
オープンソースでGitHubやCircleCI、Slack風の機能を実装したツールはないものか…。 そこで、GitLabの出番です!
GitLabって何?
GitLabは、GitHub風なGitのバージョン管理ツールに加えて、システム開発のフロー全体をカバーする様々なツールを提供してくれます。コア機能についてはオープンソースで開発が行われており、フリーで自前のサーバに導入可能です(オープンソース版であるGitLab Community Edition (CE)はMIT License下で配布されています)。
GitLabの具体的な機能としては、Gitによるバージョン管理以外に、継続的インテグレーション・継続的デリバリー(GitLab CI/CD)、チケット管理ツール、各種コミュニケーションツール(Mattermost含む)、監視ツール(Prometheus)、Dockerイメージレジストリ(GitLab Container Registry)、Web IDEなどなど、たくさんの有用な機能を使うことができます(もちろん、フリーの範囲内で利用可能)。
上記のサービスに対応するSaaS(GitHub、CircleCI、JIRAなど)を使う場合には、どうしても費用がかかってしまいますし、別々のサービスになるので管理も大変になります。GitLabならオールインワンで、それらのサービスがフリーで手に入ります(ただし、オンプレミスに限る。もちろん、サーバの管理も必要になる)。
機能の詳細については、公式のドキュメントを参照してみてください(Core / Freeとなっているのが、オープンソースで開発されているFree版で使える機能になります)。
また、これらのサービスを活用することで、チケット駆動開発(TiDD)、テスト駆動開発(TDD)、継続的インテグレーション・継続的デリバリー(CI/CD)などのモダンな開発手法を開発プロセスに組み込んでいくことができます。
最近、Ubuntu 18.04 LTS(デスクトップ版)をインストールしたPCを用意したので、今回はこの環境にGitLabを導入してみたいと思います。また、GitLabのDockerイメージからGitLabサーバを立ててみたいと思います(SlackクローンであるMattermostも同梱されているのでこれも導入してみます)。
なぜDockerを使うのか?
以下は、個人的な意見です。Dockerは使い始めたばかりなので、間違っている箇所もあるかもしれませんが、DockerコンテナとしてGitLabを導入するメリットを挙げてみました。
GitLabのすべての構成が1つのDockerイメージに集約されている (Monolithic Image)
GitLabのDockerイメージは、すべてのツールを単一のコンテナに収めたモノリシックなDockerイメージです。そのため、NginxやPostgreSQLなどのGitLabを構成するミドルウェアのDockerコンテナを別途立ち上げる必要はありません。やることとしては、GitLabのDockerイメージをpullした後、イメージを起動させるだけです(使用者から見ると構成がシンプル)。
インフラ構成がDockerfileとしてコード化されている (Infrastructure as Code)
DockerならOS固有のインストール手順に従う必要がありません(仮想環境で実行するため、OSの違いを吸収できる)。DockerfileとしてDockerイメージの構成がコード化されており、利用者はそのファイルを実行することでDockerイメージを自動で生成することができます。そのため、インストール手順書を見ながらGitLabを導入するなんてことも必要ありません(誰でも簡単にGitLabを立ち上げることができる)。
別環境への移行が簡単 (Portability)
Dockerはポータビリティ性に優れています。新しいサーバにGitLabのシステムを移行したい場合には、既存のGitLabの環境を簡単に新しい環境に移行することが可能です。異なるOSだから、インストール方法が変わってしまう、データの引き継ぎが面倒ということはありません。
以上の観点から、中長期的にGitLabを運用していくにあたり、ホストOSに直接GitLabをインストールするのではなく、DockerコンテナとしてGitLabを運用したほうがメリットが大きいと考えられます。
検証環境
- Ubuntu 18.04 LTS (デスクトップ版)(サーバ側)
- Windows10 Pro(クライアント側)
Dockerのインストール
以下のUbuntuへのDockerのインストール方法は、Dockerの公式ドキュメントを参考にしました。詳しくは、そちらを参照のこと。
Get Docker CE for Ubuntu
https://docs.docker.com/install/linux/docker-ce/ubuntu/#install-using-the-repository
まず、aptパッケージのインデックスをアップデートします。
$ sudo apt-get update
HTTPS経由でリポジトリを使うようにするため、追加のパッケージをインストールします。
$ sudo apt-get install \ apt-transport-https \ ca-certificates \ curl \ software-properties-common
Docker公式のGPGキーを追加します。
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
GPGキー(9DC8 5822 9FC7 DD38 854A E2D8 8D81 803C 0EBF CD88
)を取得できたか確認します。
$ sudo apt-key fingerprint 0EBFCD88 pub rsa4096 2017-02-22 [SCEA] 9DC8 5822 9FC7 DD38 854A E2D8 8D81 803C 0EBF CD88 uid [ 不明 ] Docker Release (CE deb) <docker@docker.com> sub rsa4096 2017-02-22 [S]
Stable版のDockerのリポジトリを設定します。 現状、Ubuntu17.10以前のバージョンでは以下の方法でOKです。
$ sudo add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable"
一方、Ubuntu18.04の場合、まだDockerがバージョンに対応できていないので、$(lsb_release -cs)
の箇所(bionic
)をartful
に書き換えて以下のように設定します。
$ sudo add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ artful \ stable"
参考
https://linuxconfig.org/how-to-install-docker-on-ubuntu-18-04-bionic-beaver
もう一度、aptパッケージのインデックスをアップデートします。
$ sudo apt-get update
最新のStable版Dockerをインストールします。
$ sudo apt-get install docker-ce
特定のバージョンのDockerをインストールしたい場合、以下のコマンドで、インストール可能なDockerのバージョンを確認できます。
$ apt-cache madison docker-ce docker-ce | 18.03.0~ce-0~ubuntu | https://download.docker.com/linux/ubuntu artful/stable amd64 Packages docker-ce | 17.12.1~ce-0~ubuntu | https://download.docker.com/linux/ubuntu artful/stable amd64 Packages docker-ce | 17.12.0~ce-0~ubuntu | https://download.docker.com/linux/ubuntu artful/stable amd64 Packages
GitLabのDockerイメージの準備・起動
それでは、いよいよGitLabのDockerイメージの準備をしていきます。
詳しくは公式ドキュメントを参照してください。
https://docs.gitlab.com/omnibus/docker/
GitLab公式のDockerイメージはこちら。
https://hub.docker.com/r/gitlab/gitlab-ce/
まず、GitLabのDockerイメージをpullしてきます。
$ sudo docker pull gitlab/gitlab-ce
次に、GitLabのデータの永続化のために、GitLab用のファイルを保存するディレクトリをあらかじめつくっておきます(ディレクトリが存在しない場合、Docker起動後に自動的に生成されるようなので必要ないかも…)。
/home/imamachi/desktop/
は適当なディレクトリを指定してください。以下は、設定例になります。
$ mkdir -p /home/imamachi/desktop/gitlab/config $ mkdir -p /home/imamachi/desktop/gitlab/logs $ mkdir -p /home/imamachi/desktop/gitlab/data
今回は、ローカルネットワーク経由でアクセスできるようにしたいので、Ubuntuのマシンに割り当てられているIPアドレスを調べておきます。
$ ifconfig
上記のコマンドをインストールしていない場合、以下のコマンドでインストールしておきましょう。
$ sudo apt install net-tools
GitLabのDockerイメージを起動するために、以下のコマンドを実行します。
以下のオプションは、自身の環境に合わせて設定します。
--hostname
: Ubuntu(サーバ側)に割り当てられているIPアドレス
--volume
: /home/imamachi/desktop/
の部分は、先ほど作成したディレクトリのパスに合わせてください。
--name
: 起動するコンテナの名称。任意の名前でOKですが、わかりやすくgitlabにしておきました。
sudo docker run --detach \ --hostname 192.168.100.114 \ --publish 443:443 --publish 80:80 --publish 22:22 --publish 8001:8001 \ --name gitlab \ --restart always \ --volume /home/imamachi/desktop/gitlab/config:/etc/gitlab \ --volume /home/imamachi/desktop/gitlab/logs:/var/log/gitlab \ --volume /home/imamachi/desktop/gitlab/data:/var/opt/gitlab \ gitlab/gitlab-ce:latest
--volume
の内容をまとめると、以下の通り。
ローカルディレクトリ | コンテナ内ディレクトリ | 内容 |
---|---|---|
/home/imamachi/desktop/gitlab/config | /etc/gitlab | GitLabの設定ファイルを格納 |
/home/imamachi/desktop/gitlab/logs | /var/log/gitlab | GitLabのログファイルを格納 |
/home/imamachi/desktop/gitlab/data | /var/opt/gitlab | GitLabの各種データを格納 |
--publish
では、サービスごとのポート番号(ホストOS側 : Dockerコンテナ側)を指定しています。
サービス等 | ポート番号 |
---|---|
HTTPS | 443 |
HTTP | 80 |
SSH | 22 |
Mattermost | 8001 |
--restart
にalways
を設定しておくと、ホストOSをリブート(再起動)したときに、自動的にGitLabのDockerイメージを起動させることができます。特別な理由がない限り、この設定でOKだと思います。
毎回、上記のコマンドをコピペして実行していたら面倒なので、Dockerのコマンド類をmakefileにまとめて置くと便利です。
以下は、GitLab用のmakefileの例です。
start: sudo docker run --detach \ --hostname 192.168.100.114 \ --publish 443:443 --publish 80:80 --publish 22:22 --publish 8001:8001 --publish 9090:9090 \ --name gitlab \ --restart always \ --volume /home/imamachi/Desktop/gitlab/config:/etc/gitlab \ --volume /home/imamachi/Desktop/gitlab/logs:/var/log/gitlab \ --volume /home/imamachi/Desktop/gitlab/data:/var/opt/gitlab \ gitlab/gitlab-ce:latest restart: sudo docker restart gitlab stop: sudo docker stop gitlab rm: sudo docker rm gitlab
例えば、GitLabのDockerイメージの起動は以下のコマンドで実行可能になります。
$ make start
Ubuntuにmakeコマンドがインストールされていない場合、以下のコマンドでインストールしてください。
$ sudo apt install make
GitLabの起動が完了したかどうか確認するために、Dockerイメージの起動時に設定したGitLabのログファイルの出力先(上の例では、/home/imamachi/Desktop/gitlab/logs
)を参照します。
logs
ディレクトリ直下のreconfigure
ディレクトリ内に*.log
ファイルが出力されるはずです。コンテナ起動中は、随時ログ情報が書き込まれていきます。
起動が正常に完了すると、最後に以下のログが出力されるはずです。
[2018-04-28T22:33:27+00:00] INFO: Running report handlers [2018-04-28T22:33:27+00:00] INFO: Report handlers complete
GitLabにアクセスしてみる
http://<IPアドレス>
から、GitLabにアクセスすることができます(上記の例では、http://192.168.100.114
)。
初期画面では、rootユーザのパスワードの設定画面が表示されます。任意のパスワードを設定して、Change your password
をクリックします。
次に、ログイン画面が表示されるので、rootユーザもしくは新規にユーザを作成(Register)してGitLabにログイン(Sign In)します。
初回ログインでは、以下のスタートメニューが表示されます。
SSHキーの設定
公開鍵認証によりGitLabとやり取りをするために、SSHキーの設定を行います。
Windows10の場合
WindowsではおなじみのPuTTY Keyだとうまく行かなかったので、OpenSSHにしました。
こちらのGitのサイトから、Git for Windowsをインストールしておきます。
https://git-scm.com/download/win
また、Git用のクライアントアプリとして、SourceTreeをインストールしておきます。
https://ja.atlassian.com/software/sourcetree
Git for Windowsのインストールが完了したら、Git Bashを起動します。
Git Bash上で、以下のコマンドから、SSHキーを生成します。
$ ssh-keygen -t rsa
すると、C:\Users\<ユーザ名>\.ssh
以下にid_rsa.pub
という名前の公開鍵が生成されるので、テキストエディタなどでファイルを開き、ファイルの中身をコピーします。
User SettingsのSSH Keysの画面から、先ほどコピーしたSSHキーをKey欄に貼り付けます(Titleも自動的につきます)。内容に問題がなければ、Add Key
をクリックしSSHキーを登録します。
SSH Keysを再度クリックして見ると、以下のようにSSHキーが登録されていることが確認できると思います。
今度は、SourceTreeを起動し、先ほど用意した秘密鍵の方を設定しておきます。 SourceTreeの[ツール] -> [オプション]をクリックします。
SSHクライアントの設定で、SSHキーに先ほど用意した秘密鍵をセットします。
SSHクライアントには、OpenSSH
を設定します。
続いて、GitLab上のリモートレポジトリを取得します。 まず、GitLab上でリポジトリを作成し、赤枠で囲んだリポジトリのパスをクリップボードにコピーします。
SourceTreeのCloneタブから、先ほどコピーしたリポジトリのパスをペーストします。 「クローン」ボタンをクリックすると、ローカルにリモートリポジトリのクローンを作成できます。
Ubuntuの場合(MacOSの場合もほぼ同様)
以下のコマンドから、SSHキーを生成します。
$ ssh-keygen -t rsa
すると、~/.ssh
以下にid_rsa.pub
という名前の公開鍵が生成されるので、ファイルの中身をコピーします。
例えば、cat
コマンドでファイルの中身をコンソールに出力し、内容をコピーしていきます。
$ cat ~/.ssh/id_rsa.pub
(余談)クリップボードへのコピー
上記のように、手作業でコピーしているとミスを誘発する可能性があるので、できればやりたくないです。そこで、コマンド操作でクリップボードへコピーする方法を取ります。
xsel
コマンドは標準でUbuntuに入っていないので、以下のコマンドでインストールしておきます(何かと使うので入れておくと便利です)。
$ sudo apt install xsel
以下のように、クリップボードへファイルの中身をコピーすることが可能です。でも、xsel
のコマンドオプションが2つもあって面倒くさいです…。
$ cat ~/.ssh/id_rsa.pub | xsel --clipboard --input
なので、MacOSのpbcopy
と同じ名前のエイリアスをつけておきます(名前はわかりやすければ何でもいいです)。
$ echo "alias pbcopy='xsel --clipboard --input'" >> ~/.bashrc $ source ~/.bashrc
すると、以下のコマンドでクリップボードにファイルの中身をコピーできるようになります。
$ cat ~/.ssh/id_rsa.pub | pbcopy
User SettingsのSSH Keysの画面から、先ほどコピーしたSSHキーをKey欄に貼り付けます(Titleも自動的につきます)。内容に問題がなければ、Add Key
をクリックしSSHキーを登録します。
SSH Keysを再度クリックして見ると、以下のようにSSHキーが登録されていることが確認できると思います。
以降の処理は、Windowsと同じなので割愛します。
参考
公開鍵暗号を用いてのSSH接続(きほん)
https://qiita.com/mukoya/items/f20def019e25dc162ca8
コマンドラインからクリップボードへのコピー
https://qiita.com/Kzno/items/6f2fa98256bdffb0fd43
MattermostへGitLabのアカウントでシングルサインオン(SSO)する
GitLabに同梱されているMattermostは、別途Mattermost用のアカウントを作成しなくても、GitLabのアカウントからログインすることができます(シングルサインオン(SSO))。
以下では、GitLabアカウントでのシングルサインオンを行うための設定について紹介します。
ブラウザからGitLabにアクセスし、rootユーザでログイン後、Settingsから、
Applicationsタブに移動し、Mattermostという名前のアプリケーションをGitLabに登録します。
Redirect URIには、以下のURIを指定します(IPアドレスにはホストOSに割り当てられている値を設定してください。ここでは、192.168.100.114
にしています)。
http://192.168.100.114:8001/signup/gitlab/complete http://192.168.100.114:8001/login/gitlab/complete
同じサーバで運用している場合、以下のようにMattermostのポート番号も指定する必要があります。そうしないと、リダイレクトに失敗してしまうので注意です。
Save application
ボタンをクリックし、登録を完了してください。登録に成功すると、以下の画面が表示されます。ここで、Application id
とSecret
の値を次に使うので、控えておいてください。
詳しくは以下を参考のこと。
https://docs.gitlab.com/omnibus/gitlab-mattermost/
続いて、GitLabの設定ファイルを変更します。
まず、一時的にgitlab.rb
を編集可能にしておきます(もしくはVimで編集)。
$ cd /home/imamachi/desktop/gitlab/config/ $ sudo chmod 755 gitlab.rb
1125行目辺りにある、以下を編集します。
http://<IPアドレス>:8001
と設定します。
mattermost_external_url 'http://192.168.100.114:8001'
1219-1225行辺りにある、以下をコメントアウトをはずして内容を編集します。
gitlab_enable
: true
に変更。
gitlab_id
: 先ほどのApplication id
を指定。
gitlab_secret
: 先ほどのSecret
を指定。
gitlab_auth_endpoint
: http://<IPアドレス>/oauth/authorize
を指定。
gitlab_token_endpoint
: http://<IPアドレス>/oauth/token
を指定。
gitlab_user_api_endpoint
: http://<IPアドレス>/api/v4/user
を指定。
mattermost['gitlab_enable'] = true mattermost['gitlab_id'] = "abfb91bd4ebd564d515be4f3d34cb3feb23eeb30a1d47b21548e3f9a63d2b502" mattermost['gitlab_secret'] = "1e60f2d1148c712a69a3771ccf095db8dd812f482e98360c3b7e0330f168eae7" mattermost['gitlab_scope'] = "" mattermost['gitlab_auth_endpoint'] = "http://192.168.100.114/oauth/authorize" mattermost['gitlab_token_endpoint'] = "http://192.168.100.114/oauth/token" mattermost['gitlab_user_api_endpoint'] = "http://192.168.100.114/api/v4/user"
GitLabのDockerコンテナを一旦停止させて、破棄します。
$ sudo docker stop gitlab $ sudo docker rm gitlab
makefileを用意していれば、以下のコマンドで実行できます。
$ make stop $ make rm
続いて、Dockerコンテナを起動します。
$ sudo docker run --detach \ --hostname 192.168.100.114 \ --publish 443:443 --publish 80:80 --publish 22:22 --publish 8001:8001 \ --name gitlab \ --restart always \ --volume /home/imamachi/desktop/gitlab/config:/etc/gitlab \ --volume /home/imamachi/desktop/gitlab/logs:/var/log/gitlab \ --volume /home/imamachi/desktop/gitlab/data:/var/opt/gitlab \ gitlab/gitlab-ce:latest
makefileを用意していれば、以下のコマンドで実行できます。
$ make start
参考
https://docs.gitlab.com/omnibus/docker/
https://docs.gitlab.com/omnibus/gitlab-mattermost/
GitLabのDockerコンテナを起動した後、http://<IPアドレス>:8001/
にアクセスします(ここまでの例では、http://192.168.100.114:8001/
)。すると、GitLab Mattermostのログイン画面が表示されます。
リダイレクトが正しく設定されていると、GitLab Single Sign-On
をクリックした後、以下の画面が表示されます。
Authorize
ボタンをクリックすると、Mattermostにログインできます。Create a new team
をクリックし、
チーム名を入力して登録すると、
Mattermostのメイン画面が表示されるはずです。
基本的な準備は、以上で完了です。
まとめ
- GitLabのDockerイメージの準備・起動
- GitLabへのSSHキーの設定
- Mattermostの起動(GitLabアカウントによるSSO)
今回、上記の3つについて、やり方をまとめてみました。他にも、重要なこととしてバックアップのとり方や、サーバ監視などがありますが、今回は割愛しました。以下に、公式のドキュメントのリンクを示すのにとどめておきます。
Backing up and restoring GitLab
https://docs.gitlab.com/ee/raketasks/backup_restore.html#restore-for-omnibus-installations
GitLab Prometheus
https://docs.gitlab.com/ee/administration/monitoring/prometheus/
Windows10もしくはMacOSからUbuntu 18.04 LTSにリモート接続(リモートデスクトップ)してみた
Ubuntu 18.04 LTS(デスクトップ版)にWindowsもしくはMacOSからアクセス方法(いわゆる、リモートデスクトップのやり方)の紹介です。ネットで調べてみるといろいろな情報が散見されており、個人的にわかりにくかったのでやり方をまとめてみました。
以下では、VNCによるWindowsもしくはMacOSからUbuntu 18.04 LTS(デスクトップ版)へのリモート接続方法を示しました。ちなみに、サーバ版のUbuntuではやり方が異なるので注意してください。
使用したOS
注意事項
Ubuntu17.10で初めて採用されたディスプレイサーバの「WayLand」では、現在、以下の方法でリモート接続できません(Ubuntu18.04 LTSではデフォルトで「Xorg」が採用されているので大丈夫です)。
1. Ubuntu18.04 LTS側での設定
以下では、Ubnutu18.04における設定方法を示しました。 まず、設定から「共有」をオンにし、画面共有をアクティブにします。
以下の詳細設定では、「このスクリーンの操作する接続を許可する」にチェック、アクセスオプションの「パスワードを要求する」にチェックをつけます。
このとき、「新規接続の場合アクセス要求を必要とする」にチェックすると、Ubuntu側で接続要求を許可するかどうか毎回確認が入るので、パスワードの要求のほうが便利です。
さらに、Windowsからリモート接続する場合、通信の暗号化処理をオフにしておく必要があります(通信内容が暗号化されなくなるので、セキュリティ的に問題があります。リモート接続はローカルネットワークなどの限定された範囲で行ったほうが良さそうです)。
$ sudo gsettings set org.gnome.Vino require-encryption false
また、すでにファイアウォールの設定がされているかどうか確認します。
$ sudo ufw status 状態:非アクティブ
となっていれば、ファイアウォールが有効になっていないのでリモート接続できる状態にあります。
ファイアウォールが有効になっている場合、以下のように5900番ポートを許可する設定を行います。
$ sudo ufw allow 5900 $ sudo ufw reload $ sudo ufw status
2. Windows10の設定
好きなVNC Viewerを使って、Ubuntuにリモート接続します。Windowsにデフォルトで入っているリモートデスクトップアプリは通信プロトコルが異なるため利用できません。
ここでは、TightVNCを使いました。オープンソースで開発されており、フリーで利用可能です。いくつかのViewerを使ってみたところ、TightVNCが最も軽快に動作する印象でした。
以下のサイトからダウンロードします。
www.tightvnc.com
インストールするといろいろなアプリが入ってきますが、Viewerである「TightVNC Viewer」をクリックして起動します。
「Remote Host」にローカルネットワーク上のIPアドレス(Ubnutu側)を入力し、ポート番号を「5900」に設定します。
Ubuntu側のPCに割り当てられているIPアドレスがわからない場合は、以下のコマンドで調べることができます。
$ ifconfig
接続に問題がなければ、Ubnutu側で設定したパスワードを入力する画面が出てきます。
パスワードを入力した後、OKボタンをクリックするとUbuntu側のPCにリモート接続できるはずです。
3. MacOSの設定
次に、MacOSからUbuntu側へのリモート接続を試したいと思います。
まず、Finderの「移動」から「サーバへ接続」をクリックします。
サーバアドレスにローカルネットワークのIPアドレス(Ubuntu側のもの)とポート番号を入力します。
この時、「+」ボタンをクリックし、設定を保存しておくと次回以降の接続が簡単になります。
接続に問題がなければ、Ubuntu側で設定したパスワードを入力する画面が出てきます。
パスワードを入力した後、OKボタンをクリックするとUbuntu側のPCにリモート接続できるはずです。
4. おまけ
4月26日にリリースされたUbuntu 18.04 LTSをインストールしたらとりあえずやっておきたいことをまとめました。
とりあえずアップデート
インターネットに接続していれば、自動でアップデートがかかるので更新しておく。 続いて、以下のコマンドでアップデートをかける。
$ sudo apt update $ sudo apt upgrade
ifconfigとmakeコマンドを使えるようにする
$ sudo apt install net-tools $ sudo apt install make
日本語名のディレクトリを英語表記に変更する
フォルダ名が日本語なのは使いにくいので、以下で一括で英語表記に設定。 ウインドウが表示されるので、「Update Names」をクリックしディレクトリ名を変更する。
$ LANG=C xdg-user-dirs-gtk-update
変更されると、以下のようになる。
もしくは、すでに自力でディレクトリ名を変更してしまった場合は、以下の方法で新しいディレクトリ名とデスクトップやドキュメントなどのリンクを対応付けする。
cd ~/.config sudo chmod 755 user-dirs.dirs code user-dirs.dirs
VSCodeで編集。
# This file is written by xdg-user-dirs-update # If you want to change or add directories, just edit the line you're # interested in. All local changes will be retained on the next run # Format is XDG_xxx_DIR="$HOME/yyy", where yyy is a shell-escaped # homedir-relative path, or XDG_xxx_DIR="/yyy", where /yyy is an # absolute path. No other format is supported. # XDG_DESKTOP_DIR="$HOME/desktop" XDG_DOWNLOAD_DIR="$HOME/download" XDG_TEMPLATES_DIR="$HOME/templates" XDG_PUBLICSHARE_DIR="$HOME/share" XDG_DOCUMENTS_DIR="$HOME/document" XDG_MUSIC_DIR="$HOME/music" XDG_PICTURES_DIR="$HOME/picture" XDG_VIDEOS_DIR="$HOME/video"
chmod 600 user-dirs.dirs
日付表示
$ gsettings set org.gnome.desktop.interface clock-show-date true
参考
Ubuntu 17.10のインストール直後にやっておきたいことまとめ
https://linuxfan.info/ubuntu-17-10-basic-settings
https://qiita.com/scapegoat_11_/items/3ff95addfabef8f9d10d
Dockerコンテナ上でNGSのソフトウェアを実行してみる(Windows10・MacOSXローカル環境編)
きっかけ
近年では、BiocondaのようなBiology関連ソフトウェアに対するパッケージマネージャが登場し、NGS関連のソフトウェアのインストールがグッと簡単になりました(Biocondaが登場する前は、いちいちソースコードからコンパイルする必要があったり、各ソフトウェア固有のインストール方法を理解する必要があったり、とにかく手間がかかっていました…。NGS関連のソフトは依存関係が複雑で本当にやっかい)。
ただ、いろんな人のNGS関連のブログを見ていると、環境によってはBiocondaでうまくインストールできないという事例もあるようです(Biocondaレシピで想定されていなかったパッケージへの依存によるもの?)。確かに、Biocondaは非常に便利なんですが、他の環境でも同じ解析環境を構築しようとすると、再現よく環境を構築できないケースがあることがわかってきました。
そこで、ソフトウェアごとに仮想環境を構築し、各ソフトウェアの動作が保証された環境を色々な解析に使いまわすことで、上記の問題を解決しようと考えました。
そこで、Dockerの出番です。Dockerはコンテナ型仮想化技術の1つであり、ホストOS上で単一のプロセスとして起動します。ホストOSと同じカーネルを共有するため、VMWare, VirtualBoxなどのホスト型仮想化技術と比較して、軽量であるとされています。
「Docker」を全く知らない人のために「Docker」の魅力を伝えるための「Docker」入門
https://qiita.com/bremen/items/4604f530fe25786240db
前置きが長くなりましたが、今回は、Dockerを土台としたシステム基盤をつくることを考えるために、まずはローカル環境でDockerコンテナを動かしてみた (FastQCを実行して見る)という内容になります。
Dockerをベースにした解析パイプラインの活用事例
パッと目についた事例をあげてみました。他にもたくさんあると思います。
High-Throughput Genomics on AWS - LFS309 - re:Invent 2017
AWSのカンファレンス re:Invent 2017で紹介されたNGS解析のパイプライン
https://www.slideshare.net/AmazonWebServices/highthroughput-genomics-on-aws-lfs309-reinvent-2017
Broad Institute: Genomes-in-the-cloud
Broad Instituteで利用されているゲノム解析用のパイプライン
https://hub.docker.com/r/broadinstitute/genomes-in-the-cloud/
BioContainers
バイオインフォマティクス関連のDockerイメージファイルをまとめたもの
https://biocontainers.pro/
ベースとなるDockerイメージの選択
NGSのデータ解析をする上では、必要最小限のLinuxディストリビューションのDockerイメージを使用した方がいいと思います。1つはイメージサイズが小さいほど、Dockerイメージの起動や破棄、ダウンロードなどの取り回しの面で有利だから。もう1つは、軽量コンテナの方が不要なパッケージが少なく、セキュリティ上、潜在的な攻撃を受けにくいからです。
また、ベースイメージを選定する上で、OSにインストールマネージャーがついているかどうかや、ITベンダーなどにより定期的にメンテナンスされているかどうかもポイントになります。
以下では、主要なLinuxディストリビューションについて簡単に比較をして見たいと思います。
Dockerイメージのサイズ
以下が主要なLinuxディストリビューションのDockerイメージのサイズになります。
Linux OS | Compressed size |
---|---|
debian8.10-slim | 30 MB |
debian 8.10 | 53 MB |
ubuntu 18.04 | 35 MB |
centos 7.4.1708 | 73 MB |
上記のデータは、2018-03-13時点のデータです。少し前までは、Debianが軽量なDockerイメージだったので、Debian一択なのかと思っていましたが、Ubuntuも直近ではかなりスリム化を果たしていますね(ちなみに、Anacondaやその他NGS関連のDockerイメージはDebianをベースに作られたものが多い気がします)。
脆弱性レポート
各Dockerイメージのレポジトリのtag
タブから、各バージョンの脆弱性レポートを確認することができます。
スキャンされた各イメージをクリックすると、詳細を見ることができます。以下では、各LinuxディストリビューションのDockerイメージの脆弱性レポートを見ていくことにします。
debian8.10-slim
debian 8.10
ubuntu
centos 7.4.1708
脆弱性レポートまとめ
上記で示した脆弱性レポートの結果をまとめて見ました。いくつのコンポーネントが脆弱性を抱えているかカウントした表が以下の通りになります。
Linux OS | Vulnerability (Components) |
---|---|
debian8.10-slim | 6 |
debian 8.10 | 6 |
ubuntu 18.04 | 0 |
centos 7.4.1708 | 16 |
上記のデータは、2018-03-13時点のデータです。Ubuntuが脆弱性が0なのが際立っている気がします(本当かなって結果になりました)。
現状では、Debian-slimかUbuntuを選択するのが良いのかなと思いました。
Dockerのインストール
自身のパソコンにDockerをインストールします。
以下のURLから、Docker (Community Edition)をダウンロードできます。
https://www.docker.com/community-edition#/download
MacOSXにDockerをインストールして使う場合は以上でインストール完了です。
Windows10環境の場合、既存のコマンドプロンプトやPowershellがどうも使いにくい(個人的な感想ですが)ので、Windows Subsystem for Linux (WSL)を導入して、BashシェルからDockerを扱えるようにしたいと思います。
Windows Subsystem for Linux (WSL)経由でホストOS (Windows10)のDockerを動かす
1. WSLをインストールする
注意: Dockerを使用するにはHyper-Vを利用する必要があるため、OSがWindows10 Proであることが必須です。
Miscrosoft storeからWSLをダウンロード・インストールできるようになったので、ストアからインストールしましょう。今回はUbuntuを導入しました。
WSLを使用するためには、「プログラムと機能」から「Windowsの機能の有効化または無効化」を開き、Windows Subsystem for Linuxにチェックをつけます。
2. DockerをWSLにインストールする
以下のUbuntuへのDockerのインストール方法は、Dockerの公式ドキュメントを参考にしました。詳しくは、そちらを参照のこと。
Get Docker CE for Ubuntu
https://docs.docker.com/install/linux/docker-ce/ubuntu/#install-using-the-repository
WSLのBash shellを起動し、まずaptパッケージをアップグレードしておきます。
$ sudo apt-get update
次のDockerを動かすために必要な各種パッケージをインストールします。
$ sudo apt-get install \ apt-transport-https \ ca-certificates \ curl \ software-properties-common
Dockerの公式のGPGキーを加え、キー情報の確認を行っています。
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - $ sudo apt-key fingerprint 0EBFCD88 pub 4096R/0EBFCD88 2017-02-22 Key fingerprint = 9DC8 5822 9FC7 DD38 854A E2D8 8D81 803C 0EBF CD88 uid Docker Release (CE deb) <docker@docker.com> sub 4096R/F273FCD8 2017-02-22
Dockerをインストールします。
$ sudo add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" $ sudo apt-get update $ sudo apt-get install docker-ce
3. WSL側とホストOS (Windows10)側のDockerを連携させる
Docker for Windowsのデーモンに接続するための設定を行います。今の状態では、あくまでホストOS側(Windows10)とWSL側で別々にDockerをインストールしただけなので、WSL側から、ホストOS側のDockerのデーモンプロセスを操作できるのように連携させる必要があります。
以下のように、WSL側のDockerクライアントからホストOS側のデーモンを見れるように、環境変数DOCKER_HOST
を設定します。
$ echo "export DOCKER_HOST='tcp://0.0.0.0:2375'" >> ~/.bashrc $ source ~/.bashrc
最後に、Windows10側のDockerの設定画面を開き、Expose daemon on tcp://localhost:2375 without TLS
にチェックを付けます。これで、WSL側からホストOS側のDockerのデーモンを操作できるようになりました。
参照
Docker for Windowsで快適な環境を得るまでの そこそこ長い闘い
https://qiita.com/YukiMiyatake/items/73c7d6c4f2c9739ebe60
WSL(Bash on Windows)でDockerを使用する
https://qiita.com/yoichiwo7/items/0b2aaa3a8c26ce8e87fe
Docker for WindowsをWSLから使う時のVolumeの扱い方
https://qiita.com/gentaro/items/7dec88e663f59b472de6
VSCodeの総合ターミナルでWSLを使う
VSCodeでは、エディタ内でターミナルを開くことができるので、こちらの標準のターミナルをWSLに変更しておくと便利です。
まず。設定画面から、terminal.integrated.shell.windows
で検索します。
対象の設定に対して "terminal.integrated.shell.windows": "C:\\Windows\\System32\\bash.exe"
のようにWSLのBash.exeのパスを指定します。
総合ターミナルを開いて確認すると、めでたくBashシェルが使えるようになっているはずです!
Dockerファイルの作成
まず、Linux OSのDockerイメージをベースイメージにして、その上にNGS解析のソフトウェアをインストールしたDockerイメージを作成します。
1. Debian9-slimにBiocondaをインストールしたDockerイメージを作成する
Linux OSのDebina9-slim
をベースイメージにして、BiocondaをインストールしたDockerイメージを作成します。
以下のDockerfileは、condaの公式Dockerfileを参考しました。
https://hub.docker.com/r/conda/miniconda2/~/dockerfile/
&&
で処理を連続して行っているのは、レイヤーを減らすためです。また、中間ファイルを削除することでDockerのイメージファイルのサイズを小さくしています。
Dockerfile
# Base image FROM debian:9-slim # Install Miniconda2 & Bioconda RUN apt-get -qq update && apt-get -qq -y install curl bzip2 \ && curl -sSL https://repo.continuum.io/miniconda/Miniconda2-latest-Linux-x86_64.sh -o /tmp/miniconda.sh \ && bash /tmp/miniconda.sh -bfp /usr/local \ && rm -rf /tmp/miniconda.sh \ && conda install -y python=2 \ && conda update conda \ && conda config --add channels r \ && conda config --add channels defaults \ && conda config --add channels conda-forge \ && conda config --add channels bioconda \ && apt-get -qq -y remove curl bzip2 \ && apt-get -qq -y autoremove \ && apt-get autoclean \ && rm -rf /var/lib/apt/lists/* /var/log/dpkg.log \ && conda clean --all --yes ENV PATH /opt/conda/bin:$PATH
次に、DockerfileからDockerイメージを作成します。
$ docker build -t debian9-slim-bioconda2:latest -f Dockerfile .
2. FastQCをインストールしたDockerイメージを作成する
先程作ったDockerイメージをベースにして、FastQCのインストールしたイメージファイルを作成します。
Dockerfile
# Base image FROM debian9-slim-bioconda2:latest # Application entry point # Dejavu fonts are not included with default::openjdk(fastqc recipe). # They are already included with conda-forge::openjdk. # https://github.com/conda-forge/staged-recipes/issues/3164 RUN conda update conda \ && conda install fastqc=0.11.6 \ && conda install -c conda-forge openjdk \ && conda clean --all --yes COPY ./fastqc/run_fastqc_local.py /run_fastqc_local.py ENTRYPOINT ["python", "/run_fastqc_local.py"]
Pythonのコードをエントリポイントに設定します。以下が、そのソースコードになります。
from __future__ import print_function import os import shlex import subprocess from argparse import ArgumentParser def run_fastqc(fastq_path, cmd_args, working_dir): """ Runs fastqc :param fastq_path: Local path to fastq file :param cmd_args: Additional command-line arguments to pass in :param working_dir: Working directory :return: Path to the result folder """ # Prepare fastqc result path fastqc_result_dir = os.path.join(working_dir, '') # Prepare fastqc log path fastqc_log_path = os.path.join(fastqc_result_dir, "log_fastqc.txt") # Prepare fastqc command cmd = "fastqc -o {0} {1} {2}".format( fastqc_result_dir, cmd_args, fastq_path) print(cmd) # Execute fastqc with open(fastqc_log_path, 'w') as log_file: subprocess.check_call(shlex.split(cmd), stdout=log_file) return fastqc_result_dir def main(): argparser = ArgumentParser() argparser.add_argument('--fastq_path', type=str, help="fastq sequence file", required=True) argparser.add_argument('--cmd_args', type=str, help="arguments/options for fastqc", default="") argparser.add_argument('--working_dir', type=str, default="data/") args = argparser.parse_args() print("Creating working directory...") if not os.path.exists(args.working_dir): os.mkdir(args.working_dir) print("Running fastqc...") local_result_dir = run_fastqc( args.fastq_path, args.cmd_args, args.working_dir) print('Save the result in {0}.'.format(local_result_dir)) print("successfully Completed !!") if __name__ == '__main__': main()
次に、DockerfileからDockerイメージを作成します。Pythonのコードも同じディレクトリに置いておきます。
$ docker build -t debian9-slim-bioconda2-fastqc:latest -f Dockerfile .
以下のコマンドで作成したDockerイメージをチェックできます。
$ docker images
Dockerイメージの実行
1. FASTQファイルの準備
適当なFASTQファイルを持っていない場合、以下の記事を参考にしてテストに使うFASTQファイルを用意してください。
2. Dockerコンテナを起動する
FASTQ_FILE
にFASTQファイル、FASTQファイルが置いてあるLOCAL_WORKING_DIR
に作業ディレクトリを指定します。また、DOCKER_IMAGE
に先ほど作成したDockerイメージを、DOCKER_WORKING_DIR
にDockerコンテナ内の適当な作業ディレクトリを指定します。
#!/bin/bash #LOCAL_WORKING_DIR="/Users/imamachinaoto/Desktop/NGS/data" # MacOS LOCAL_WORKING_DIR="/c/Users/imama/Desktop/NGS/fastqc/data" # Windows10(WSL) DOCKER_WORKING_DIR="/data" DOCKER_IMAGE="debian9-slim-bioconda2-fastqc:latest" FASTQ_FILE="RefSeq_hg38_2015-08-19_NM_ultraSlim.fq" docker run --rm -it \ -v ${LOCAL_WORKING_DIR}:${DOCKER_WORKING_DIR} \ ${DOCKER_IMAGE} \ --fastq_path ${DOCKER_WORKING_DIR}/${FASTQ_FILE} \ --working_dir ${DOCKER_WORKING_DIR}
ちなみに、DockerでWSL環境からホストOS(Windows10)のフォルダを見るとき、Cドライブは/mnt/c
ではなく、/c
です。Bashシェルからアクセスするときは、/mnt/c
(WSLにマウントされているCドライブを見る形)なのでパスの違いに注意が必要です。Windowsだと、これで詰まりました…。
コンテナでデータを管理する
http://docs.docker.jp/engine/userguide/dockervolumes.html
上記のシェルスクリプト(もしくは以下で説明するmakeコマンド)を実行することで、FastQCが実行されます。
ホストOSのディレクトリを、Docker上のディレクトリに紐づけておくこと(ボリュームのマウント)で、以下のようにDockerコンテナが破棄されたあとでも、データを永続化させることができます。
Dockerコマンドをまとめたmakefileの作成
Dockerコマンドはイメージファイルの作成やコンテナ起動時など、繰り返し使用します。なので、今回はmakefileにコマンド類をまとめて、make build
やmake start
などを用意することで、コマンド操作が簡単になります。
Windows10やWSLには、makeコマンドがインストールされていないため、あらかじめインストールしておきます。
Windows10でmakeファイルを実行する
WSLを使わない場合のmakeコマンドのインストール方法を示します。Windows10にはコマンドプロンプトからmakeコマンドを使えないので、まずmakeコマンドをインストールします。
1. makeコマンドをコマンドプロンプトに導入する(参考)
以下のURLから、makeをダウンロードします。
http://gnuwin32.sourceforge.net/packages/make.htm
C:\Program Files (x86)\GnuWin32\bin
にmake.exeが保存されているので、パスを通します。
2. WSL環境にmakeコマンドを導入する
WSLのコンソールから、以下のコマンドを実行するだけです。
$ sudo apt-get install make
Windowsでmakeコマンドを使う
https://qiita.com/tokikaze0604/items/e13c04192762f8d4ec85
makefileの例
NAME=debian9-slim-bioconda2-fastqc TAG=0.11.6.local UNDERSCORE_TAG=0_11_6_local LOCAL_WORKING_DIR=/c/dev/NGS/fastqc/data DOCKER_WORKING_DIR=/data DOCKER_IMAGE="fastqc-aws-debian9-slim-bioconda2:0.11.6.local" FASTQ_FILE=RefSeq_hg38_2015-08-19_NM_ultraSlim.fq all: build push build: docker build -t $(NAME):$(TAG) -t $(NAME):latest -f Dockerfile . build-no-cache: docker build --no-cache -t $(NAME):$(TAG) -t $(NAME):latest -f Dockerfile . push: docker push $(NAME):$(TAG) docker push $(NAME):latest start: docker run --rm -it -v ${LOCAL_WORKING_DIR}:${DOCKER_WORKING_DIR} ${DOCKER_IMAGE} --fastq_path ${DOCKER_WORKING_DIR}/${FASTQ_FILE} --working_dir ${DOCKER_WORKING_DIR} rm: docker rm `docker ps -aq` rmi: docker rmi $(NAME):$(TAG) $(NAME):latest
つまづいたポイント
makefileの作成
インデントはスペースではなく、タブにしないとエラーになる。
Visual Studio Codeの場合、makefileと認識されたファイルでは、インデントをタブにするように設定されている。しかし、ファイル名がMakefile
だと下記の設定が適応されない。makefile
と小文字のmにする必要がある。
Docker関連の参考
docker コマンド チートシート
https://qiita.com/voluntas/items/68c1fd04dd3d507d4083
dockerで
https://qiita.com/lirispp/items/06fc74c5bbc64fddf9ab
ART: シミュレーション用のRNA-seqデータを作成する
テスト用のFASTQファイルの作成
ART (a next-generation sequencing read simulator)を用いて、テスト用のFASTQファイルを作成します。
ARTのインストール
※ Biocondaをインストールしていることを前提にしています。
ARTをインストールします。
$ conda intall art
ARTが正しくインストールされたか確認します。
$ art_illumina --help
RefseqのGTFファイルをダウンロード
ARTを使ってテスト用のFASTQファイルを作るのですが、今回はRNA-seqのデータを作ろうと思います。
そこで、元となる配列を用意したいと思います。 TranscriptomeのデータをGTFファイルと取得し、それをFASTQのファイルに変換したいと思います。
GencodeのGTFファイルでもいいですが、ここでは必要なTranscriptomeデータが含まれておりコンパクトなRefseqのデータを使います。
illuminaのiGenomeサイトから、hg38のデータを丸ごとダウンロードします。この中に、RefSeqのGTFファイルも含まれています。
ダウンロードしたら、解凍します。
$ tar zxvf Home_sapiens_UCSC_hg38.tar.gz
解凍が終わったら、Homo_sapiens
というディレクトリができるはずです。
Homo_sapiens/UCSC/hg38/Annotation/Archives/archive-2015-08-14-08-18-15/Genes/
にあるgenes.gtf
というファイルがRefSeqのGTFファイルになります(ちょっと古いデータですが、実際の解析に用いるわけではないので、良しとしましょう)。
これだけ適当なディレクトリに移動もしくはコピーしておき、それ以外のファイルは削除します。
このままだと、何のファイルかわからないのでリネームしておきます。
$ mv genes.gtf RefSeq_hg38_2015-08-19.gtf
GTFファイルからBEDファイルを作成
以下のスクリプトを使って、GTFファイルをBEDファイルに変換する。 gtf2bed.pl (3.8 kB)
$ perl gtf2bed.pl RefSeq_hg38_2015-08-19.gtf > RefSeq_hg38_2015-08-19.bed
このままだと、データが大きすぎるのでmRNAに限定し、かつRepresentative transcriptsをできるだけ抽出するようにします。
ExtractMrna.py (360 B)
$ python ExtractMrna.py RefSeq_hg38_2015-08-19.bed RefSeq_hg38_2015-08-19_NM_slim.bed
ヒトゲノム配列をダウンロード
$ wget http://hgdownload.soe.ucsc.edu/goldenPath/hg38/bigZips/hg38.fa.gz $ gunzip hg38.fa.gz
BEDファイルからFASTAファイルを作成
BEDファイルからFASTA ファイルへ変換するために、Bedtoolsを使います。 まず、Bioconda経由でBedtoolsをインストールします。
$ conda install bedtools
BEDファイルをFASTAファイルに変換します。 ここで、先ほどダウンロードしたhg38.faファイルを使います。
$ bedtools getfasta -name -s -split -fi hg38.fa -bed RefSeq_hg38_2015-08-19_NM_slim.bed > RefSeq_hg38_2015-08-19_NM_slim.fa
-name
: BEDファイルのname列の値を各配列の名称とする。
-s
: ゲノム上での向き (Strandness)を考慮する(Transcriptomeなのでもちろん考慮します)。
-split
: 12BED (12列のデータがあるBEDふぁいる)がInputである場合に指定 。
-fi
: Referenceになる配列(ゲノム配列)のFASTAファイルを指定。
-bed
: TranscriptomeのBEDファイルを指定。
このコマンドの実行には、FASTAファイルのインデックスファイルが必要になりますが、ファイルがない場合、自動的に生成してくれるので問題ないです。
> index file hg38.fa.fai not found, generating...
生成されたTranscriptomeのFATSAファイルは、標準出力で出力されます。
TranscriptomeのFASTAファイルからFASTQファイルを生成
今回は、illuminaのFASTQシーケンスデータ (RNA-seq, single-end)を生成したいと思います。ここでは、HiSeq2000のデータを作ります。
$ art_illumina -ss HS20 -i RefSeq_hg38_2015-08-19_NM_slim.fa -o RefSeq_hg38_2015-08-19_NM_slim -l 36 -f 2 --noALN
$ art_illumina -ss HS20 -i RefSeq_hg38_2015-08-19_NM_slim.fa -o RefSeq_hg38_2015-08-19_NM_slim_paired -l 36 -f 1 -p -m 300 -s 10 --noALN
-i
--in
: fasta形式の入力ファイルの指定。
-o
--out
: fastq形式の出力ファイルの指定 (拡張子はつけなくて良い)。
-ss
--seqSys
: シーケンサーの種類を選択。
指定する引数(System ID) - シーケンサー名 (リード長)
- GA1 - GenomeAnalyzer I (36bp,44bp),
- GA2 - GenomeAnalyzer II (50bp, 75bp)
- HS10 - HiSeq 1000 (100bp)
- HS20 - HiSeq 2000 (100bp)
- HS25 - HiSeq 2500 (125bp, 150bp)
- HS10 - HiSeq 1000 (100bp)
- HS20 - HiSeq 2000 (100bp)
- HS25 - HiSeq 2500 (125bp, 150bp)
- HSXn - HiSeqX PCR free (150bp)
- HSXt - HiSeqX TruSeq (150bp)
- MinS - MiniSeq TruSeq (50bp)
- MSv1 - MiSeq v1 (250bp)
- MSv3 - MiSeq v3 (250bp)
- NS50 - NextSeq500 v2 (75bp)
-l
--len
: リード長の指定。
-f
--fcov
: リードカバレージの指定。
-p
--paired
: Paired-endのデータとして出力(指定しない場合、Single-endのデータとして出力)。
m
--mflen
: フラグメントの平均サイズの指定(Paired-endのときのみ)。
-s
--sdev
: フラグメントのサイズの標準偏差の指定(Paired-endのときのみ)。
-sam
--samout
: SAMファイルを出力。
-na
--noALN
: アライメントファイル (ALN)を出力しない。
別にリード長は、指定された長さよりも短くても大丈夫です。
もっとファイルサイズを小さくしたい場合は、以下のように特定の行を抽出したファイルを作成します。
$ sed -n 1,200000p RefSeq_hg38_2015-08-19_NM_slim.fq > RefSeq_hg38_2015-08-19_NM_ultraSlim.fq
Seleniumコトハジメ - PubMed検索とUCSC Genome browserへのCustom Trackのアップロードを自動化してみた
はじめに
Seleniumとは、Webアプリケーションの画面操作を自動化するためのツールです。主に、Webアプリケーション開発のUIテスト時に利用するものです。また、キー入力などの操作を自動化できることから、Webスクレイピングのツールとして活用される例もあるようです。
Seleniumは、Apatch 2.0ライセンスで公開されているオープンソースのツールです。
https://www.seleniumhq.org/about/license.jsp
Seleniumの内部で使われているWebDriverは、Webブラウザを外部から遠隔操作するためのインターフェースであり、W3Cによって標準化されています(厳密には、標準化された内容と乖離する部分あり?)。
https://www.w3.org/TR/webdriver/
Selenium2では、Selenium RCと呼ばれる古い実装が残っていましたが、2016年に公開されたSelenium3では、完全にWebDriverの実装に移行しました。古い記事では、Selenium RCでの操作方法が記載されており、これは現在では動作しない方法になるので注意が必要です。
本来はUIテスト用のツールですが、今回は研究室時代にめんどくさいと思っていた作業を自動化してみました。1つはPubMedによるAdvanced Search、もう1つはUCSC Genome BrowserにCustom trackをアップロードする作業です。繰り返し同じことを繰り返す作業に対して、こういった自動化の方法は役に立ちますね。
Selenium実行サンプル
PubMed検索の自動化
UCSC Genome BrowserへのCustom Trackのアップロード
実行環境・ツール
Mac OSX Sierra (v10.12.6)
- Selenium Client for Java (v3.10.0)
- ChromeDriver (v2.35)
- GeckoDriver (v0.19.0)
- SafariDriver + Safari (v11.0.3)
Windows10 (Build 16299)
- ChromeDriver (v2.35)
- Microsoft Edge (Build 16299)
- Internet Explorer 11 (v3.9.0; 32bit)
Seleniumの導入
Seleniumを動かすのに必要なものは以下の通りです。
- Selenium Client & WebDriver Language Bindings
- 各種ブラウザのWebDriver
今回はJavaでの例を示したいと思いますが、javaであれば、MavenやGradleを使って導入する方法もあります。ただ、今回はJARファイルをダウンロードして1からプロジェクトを作っていきます。
Selenium Client & WebDriver Language Bindings
Seleniumは、Java、C#、Ruby、Python、Javascript (Node)を公式でサポートしており、それぞれの言語についてSeleniumのAPIが使えるライブラリ(Selenium Client)を用意しています。
まず、以下のサイトからJavaのSelenium Clientのファイルをダウンロードします。
selenium-java-3.xx.xx.zip
というファイルをダウンロードできるはずです。
https://www.seleniumhq.org/download/
各種ブラウザのWebDriver
続いて、各種ブラウザのWebDriverをダウンロードします。私の使っているPCはMac OSXなので、とりあえずFireFox、Google Chrome、SafariのWebDriverをそれぞれダウンロードすることにします(自身のパソコンにそれぞれのブラウザがすでにインストール済みでであることを前提とします)。
余談ですが、WebDriverはSeleniumを開発しているグループが作成しているわけではなく、Webブラウザの開発元であるGoogleやMozilla、Apple、Microsoftなどがそれぞれ開発をしています。そのため、基本的に最新バージョンのWebブラウザに対応するWebDriverを、これらのITベンダーが提供してくれる状態にあります。こういった点も、Seleniumを使うメリットですね。
Mozilla GeckoDriver (FireFox) (Selenium3.5以降でのみ動作)
以下からダウンロードします。
https://github.com/mozilla/geckodriver/releases
自身のパソコンのOSに合ったWebDriverをダウンロードしてきます。
以下のコマンドでファイルを解凍します。
$ tar zxvf geckodriver-v0.19.1-macos.tar.gz
geckodriver
という名前のWebDriverの実行ファイルが解凍されます。
Google Chrome Driver (Google Chrome)
以下からダウンロードします。
https://sites.google.com/a/chromium.org/chromedriver/
WebDriverをインストールする際は、Google Chromeのバージョンに気をつけてください。最新のものだと、対応しているバージョンはv62-64に限定されます(もちろん、以前のバージョンのWebDriverについてもダウンロード可能です)。自分のパソコンにインストールされているGoogle Chromeのバージョンを確認し、古いバージョンであれば、そのバージョンをサポートしているWebDriverをダウンロードしてください。
自身のパソコンのOSに合ったWebDriverをダウンロードしてきます。
以下のコマンドでファイルを解凍します。
$ unzip chromedriver_mac64.zip
chromedriver
という名前のWebDriverの実行ファイルが解凍されます。
SafariDriver (Safari)
Mac OSX内にすでにインストール済みです。
/usr/bin/safaridriver
の場所に存在します。
Safariの設定を変更する必要があります。 まず、Safariの環境設定を開きます。
次に、「メニューバーに'開発'メニューを表示」にチェックをつけます。
すると、メニューバーに「開発」が追加されるので、そこから「リモートオートメーションを許可」をクリックします。これで、ブラウザ側の設定は完了です。
リモートオートメーションを許可していない場合、Javaのテストコードを実行すると、以下のようなエラーが出力されます。このエラーが出た場合は、上記の設定ができてないので、設定を変更してください。
org.openqa.selenium.SessionNotCreatedException: Could not create a session: You must enable the 'Allow Remote Automation' option in Safari's Develop menu to control Safari via WebDriver. (WARNING: The server did not provide any stacktrace information)
Microsoft Edge
以下からダウンロードします。
https://developer.microsoft.com/en-us/microsoft-edge/tools/webdriver/
自身のパソコンのOSのビルドに合ったWebDriverをダウンロードしてきます。
Internet Explorer 11
設定が複雑なので、必要でない限り使わないほうが良いと思います。
こちらに詳しい使用方法が記載されているので参照してください。 保護モードの設定が、「インターネット」「イントラネット」「信頼済みサイト」「制限付きサイト」の4つで統一されていることがかなり重要です(この設定が揃っていないとWebDriverが動作しません)。
seleniumでinternet-explorer11を動かす方法
http://bitwave.showcase-tv.com/seleniumでinternet-explorer11を動かす方法/
トラブルシューティング(一部)
画面は拡大せずに、100%でないと動作しません。以下のエラーが出た場合は、拡大率を100%にしましょう。
org.openqa.selenium.SessionNotCreatedException: Unexpected error launching Internet Explorer. Browser zoom level was set to 110%. It should be set to 100%
Seleniumを動かしてみる
以下では、Eclipseがインストール済みであることを前提として説明を行います。
素のEclipseをインストールするのではなく、以下のAll-in-Oneのパッケージ(Pleiades All in One)をインストールすることをお勧めします。
http://mergedoc.osdn.jp/
1. プロジェクトファイルの作成
Seleniumを動かすためのプロジェクトファイルを作成します。 [新規] -> [Javaプロジェクト]をクリックします。
適当なプロジェクト名をつけて、「次へ」をクリックします。
先ほどダウンロードしたSelenium Clientを解凍し、libs
フォルダのjarとclient-combined-3.10.0.jar
とclient-combined-3.10.0-sources.jar
をそれぞれプロジェクトファイルに取り込みます。
まず、「ライブラリ」タブを選択し、「外部JARの追加」をクリックします。
上述のSelenium ClientのJARファイル一式を追加します。 最後に、「完了」ボタンをクリックし、プロジェクトを生成します。
すると、参照ライブラリに先ほど取り込んだSelenium ClientのJARファイルが参照されて取り込まれていることが確認できると思います。
次に、WebDriverを保存するためのフォルダを用意します。 [新規] -> [フォルダー]をクリックします。
フォルダー名を「exe」として、「完了」ボタンをクリックします。
作成した「exe」フォルダ内に、先ほどダウンロードしたWebDriverをドラック&ドロップでインポートします。(ここでは、chromedriver.exe
をインポートした例を示した。)
Mac OSXの場合、実行権限を付与しておきます。
$ chmod 755 geckodriver
続いて、Seleniumを実行するためのテストクラスを作成していきます。 プロジェクトの「src」フォルダを右クリックし、[新規] -> [Junitテスト・ケース]をクリックします。
適当なパッケージ名とクラス名を記入し、setUp()
とtearDown()
にチェックを付けます。
JUnit4がビルドパスに入っていない場合、追加するかどうか聞かれるので、「OK」をクリックしてビルドパスに加えます。
2. PubMedとUCSC Genome Browserを操作するコードを書いてみる
ページオブジェクトパターン
下図にページオブジェクトパターンと呼ばれる、一般的なクラスの設計方法を示しました。この方法を取り入れることで、メニューやボタン、検索入力欄など、Webページへの操作を共通クラスにまとめることでメンテナンス性の高いコードを書くことができます。
ロケータの調べ方
selenium用のコードを書くために、まずロケータ(ボタンやメニューなどを操作するための目印)を調べる必要があります。例えば、FireFoxを使うと、要素(下の例だと"Advanced")を右クリックして「要素を調査」をクリックすることでロケータを調べることができます。
どのタグが使われているかなどの情報を調べることができます(以下の図だと、INPUTタグのID要素が"Submit"であることがわかります。これを目印にしてSeleniumでWebブラウザを操作していきます)。
コーディング
以下のような構成で、プログラムを用意しました。 pageパッケージにページオブジェクトクラスを、testパッケージにJUnitのテストケースクラスを配置するようにしました。
WebDriverの呼び出し
System.setProperty()
の2番目の引数は、ダウンロードしたWebDriverを指定してください。OSによって、拡張子が異なるので注意する必要があります。以下でいくつか例を示しました。
Google Chrome (Mac OSX)
System.setProperty("webdriver.chrome.driver", "exe/chromedriver"); WebDriver driver = new ChromeDriver();
Firefox (Mac OSX)
System.setProperty("webdriver.gecko.driver", "exe/geckodriver"); WebDriver driver = new FirefoxDriver();
Safari (Mac OSX)
WebDriver driver = new SafariDriver();
Microsoft Edge (Windows10)
System.setProperty("webdriver.edge.driver", "exe/MicrosoftWebDriver.exe"); WebDriver driver = new EdgeDriver();
Internet Explorer (Windows10)
System.setProperty("webdriver.ie.driver", "exe/IEDriverServer.exe"); WebDriver driver = new InternetExplorerDriver();
ソースコード例
ソースコードの内容について言及しません。 主に、「Selenium実践入門」と言う本と下記のWebサイトを参考にしました。
PubMedSearchTest.java
package test; import java.util.concurrent.TimeUnit; import org.junit.After; import org.junit.Before; import org.junit.Test; import org.openqa.selenium.WebDriver; import org.openqa.selenium.chrome.ChromeDriver; import page.PubMedAdvancedSearchPage; public class PubMedSearchTest { private WebDriver driver; @Before public void setUp() throws Exception { System.setProperty("webdriver.chrome.driver", "exe/chromedriver.exe"); driver = new ChromeDriver(); //System.setProperty("webdriver.edge.driver", "exe/MicrosoftWebDriver.exe"); //driver = new EdgeDriver(); //System.setProperty("webdriver.ie.driver", "exe/IEDriverServer.exe"); //driver = new InternetExplorerDriver(); driver.manage().timeouts().implicitlyWait(5, TimeUnit.SECONDS); } @After public void tearDown() throws Exception { //driver.quit(); } @Test public void pubmedAdvancedSearchTest() { // PubMed Top PubMedAdvancedSearchPage pmPage = new PubMedAdvancedSearchPage(driver); // Go to Advanced Search page pmPage.goToAdvancedSearch(); // Set keywords pmPage.setJournal("Nature communications"); pmPage.setJournal("Nature biotechnology"); pmPage.setSearchSelect(1, "OR"); pmPage.setJournal("Nature methods"); pmPage.setSearchSelect(2, "OR"); pmPage.setJournal("Nature genetics"); pmPage.setSearchSelect(3, "OR"); pmPage.setJournal("Molecular cell"); pmPage.setSearchSelect(4, "OR"); pmPage.setJournal("eLife"); pmPage.setSearchSelect(5, "OR"); pmPage.setJournal( "PLoS biology"); pmPage.setSearchSelect(6, "OR"); pmPage.setJournal("Genome research"); pmPage.setSearchSelect(7, "OR"); pmPage.setJournal("Genes & development"); pmPage.setSearchSelect(8, "OR"); pmPage.setJournal("Nature cell biology"); pmPage.setSearchSelect(9, "OR"); // Click Search button pmPage.clickSearchButton(); } }
UCSCGenomeBrowserTest.java
package test; import org.junit.After; import org.junit.Before; import org.junit.Test; import org.openqa.selenium.WebDriver; import org.openqa.selenium.chrome.ChromeDriver; import page.UCSCGenomeBrowserUploadPage; public class UCSCGenomeBrowserTest { private WebDriver driver; @Before public void setUp() throws Exception { System.setProperty("webdriver.chrome.driver", "exe/chromedriver.exe"); driver = new ChromeDriver(); //System.setProperty("webdriver.edge.driver", "exe/MicrosoftWebDriver.exe"); //driver = new EdgeDriver(); //System.setProperty("webdriver.ie.driver", "exe/IEDriverServer.exe"); //driver = new InternetExplorerDriver(); } @After public void tearDown() throws Exception { } @Test public void test() { UCSCGenomeBrowserUploadPage gmPage = new UCSCGenomeBrowserUploadPage(driver); gmPage.goToCustomTrack(); gmPage.setGenomeRefSelect("hg19"); // Upload file gmPage.UploadFile("C://Users/imama/Desktop/test1.bed"); gmPage.submit(); // Back to custom track page gmPage.goBackToCustomTrack(); // Upload file gmPage.UploadFile("C://Users/imama/Desktop/test2.bed"); gmPage.submit(); // Back to custom track page gmPage.goBackToCustomTrack(); // Upload file gmPage.UploadFile("C://Users/imama/Desktop/test3.bed"); gmPage.submit(); } }
PubMedAdvancedSearchPage.java
package page; import java.util.concurrent.TimeUnit; import org.openqa.selenium.By; import org.openqa.selenium.WebDriver; import org.openqa.selenium.WebElement; import org.openqa.selenium.support.ui.ExpectedCondition; import org.openqa.selenium.support.ui.ExpectedConditions; import org.openqa.selenium.support.ui.Select; import org.openqa.selenium.support.ui.WebDriverWait; public class PubMedAdvancedSearchPage { /* WebDriverクラスのインスタンス */ private WebDriver driver; // 明示的な待機 WebDriverWait wait; // キーワードカウンタ private Integer keywordCounter; // コンストラクタ public PubMedAdvancedSearchPage(WebDriver driver){ this.driver = driver; this.keywordCounter = 0; this.wait = new WebDriverWait(driver, 10); } // Advanced saerch画面へ遷移 public void goToAdvancedSearch() { driver.get("https://www.ncbi.nlm.nih.gov/pubmed/"); driver.findElement(By.linkText("Advanced")).click(); // Goto PubMed Advanced search String previousURL = driver.getCurrentUrl(); System.out.println(previousURL); driver.manage().timeouts().implicitlyWait(30, TimeUnit.SECONDS); ExpectedCondition<Boolean> e = new ExpectedCondition<Boolean>() { public Boolean apply(WebDriver d) { return (d.getCurrentUrl() != previousURL); } }; wait.until(e); String currentURL = driver.getCurrentUrl(); System.out.println(currentURL); // ページタイトルが変更されるまで待ち wait.until(ExpectedConditions.titleContains("Advanced search")); } // Set journal public void setJournal(String journal) { // FieldにJournalを選択 Select select = new Select(driver.findElement(By.id("ff_" + keywordCounter))); select.selectByValue("Journal"); // Journal名を入力 WebElement searchBox = driver.findElement(By.id("fv_" + keywordCounter)); searchBox.sendKeys(journal); // カウントアップ keywordCounter += 1; } // Set search select public void setSearchSelect(Integer id, String value) { Select select = new Select(driver.findElement(By.id("fop_" + id))); select.selectByValue(value); } // Click Search button public void clickSearchButton() { driver.findElement(By.id("search")).click(); } }
UCSCGenomeUploadPage.java
package page; import java.util.concurrent.TimeUnit; import org.openqa.selenium.By; import org.openqa.selenium.WebDriver; import org.openqa.selenium.WebElement; import org.openqa.selenium.support.ui.ExpectedConditions; import org.openqa.selenium.support.ui.Select; import org.openqa.selenium.support.ui.WebDriverWait; public class UCSCGenomeBrowserUploadPage { /* WebDriverクラスのインスタンス */ private WebDriver driver; // 明示的な待機 WebDriverWait wait; // コンストラクタ public UCSCGenomeBrowserUploadPage(WebDriver driver){ this.driver = driver; this.wait = new WebDriverWait(driver, 10); driver.manage().timeouts().implicitlyWait(5, TimeUnit.SECONDS); } // Go to Custom track page public void goToCustomTrack() { driver.get("https://genome.ucsc.edu/"); driver.findElement(By.id("myData")).click(); wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("customTracksMenuLink"))); driver.findElement(By.id("customTracksMenuLink")).click(); } // Upload file public void UploadFile(String filePath) { WebElement upload = driver.findElement(By.name("hgt.customFile")); upload.sendKeys(filePath); } // Submit public void submit() { driver.findElement(By.id("Submit")).click(); } // Return Custom track page public void goBackToCustomTrack() { WebDriverWait wait2 = new WebDriverWait(driver, 10000); wait2.until(ExpectedConditions.visibilityOfElementLocated(By.id("addTracksButton"))); driver.findElement(By.id("addTracksButton")).click(); } public void setGenomeRefSelect(String genomeRef) { Select select = new Select(driver.findElement(By.id("db"))); select.selectByValue(genomeRef); } }
スクリーンショットの取り方について(トラブルシューティング)
余談ですが、Java8の場合、FileUtils(Java7以前)ではなく、FileHandler(Java8以降)なので間違いがないように。 https://github.com/SeleniumHQ/selenium/issues/4919
File tmpFile = ((TakesScreenshot)driver).getScreenshotAs(OutputType.FILE); try { FileHandler.copy(tmpFile, new File("/Users/imamachinaoto/Desktop/test.png")); } catch (IOException e) { // TODO 自動生成された catch ブロック e.printStackTrace(); }
参考
[初心者向け] JavaでSeleniumを動かす
https://qiita.com/tsukakei/items/41bc7f3827407f8f37e8
selenium get current url after loading a page
https://stackoverflow.com/questions/16242340/selenium-get-current-url-after-loading-a-page
Selenium WebDriverのwaitを活用しよう
http://softwaretest.jp/labo/tech/labo-294/
Best Practices & Tips: Selenium File Upload
https://saucelabs.com/resources/articles/best-practices-tips-selenium-file-upload