Rancher2.0 Tech Preview2 ~Create a RKE Cluster~

Rancher2.0 Tech Preview2の主要機能として追加された「Create a RKE Cluster」は、RKE(Rancher Kubernetes Engine)を利用して、AWS、Azure、DigitalOcean、Packet、vSphereに対してKubernetesクラスタを作成することができます。(※2018年2月現在)

Rancher2.0 Tech Preview2からAWS上にKubernetesクラスタを作成してみましょう。

Tech Preview2のインストールはRancher2.0 Tech Preview2についての「Get Started with Rancher 2.0」を参考にしてください。

Rancher2.0 Tech Preview2でAWS上にKubernetesクラスタを作成

1.Rancher2.0 Tech Preview2 Serverにログイン後に、「Add Cluster」ボタンをクリックします。

image.png

2.「Create a RKE Cluster」の「Select」ボタンをクリックします。

image.png

3.nameに任意名を入力(今回はaws-k8s-clusterとします。)して、「Add a new cluster」をクリックします。

image.png

4.「Configure」をクリックします。

image.png

5.「Amazon EC2」を選択し、nameに任意名を入力(今回はaws-k8s-clusterとします。)し、Countは「3」、Regionは「ap-northeast-1」、Access keyとSecret keyはAWSのIMA Management Consoleでグループとユーザを作成し、そのユーザーのものを入力します。そして、「Next:Authenticate & select a network」ボタンをクリックします。

image.png

6.vpcを選択して、「Next:Select a Security Group」ボタンをクリックします。

image.png

7.「Next:Set Instance options」ボタンをクリックします。

image.png

8.「Create」ボタンをクリックします。

image.png

9.kubernetesの構成を作成します。最後に「Create」ボタンをクリックします。

image.png

10.しばらくするとkubernetesクラスタ構築が完了します。

screencapture-35-198-222-0-g-clusters-1517843931311.png

クラスタ名をクリックすると全体のリソース状況が可視化されます。

screencapture-35-198-222-0-c-cluster-8p8bq-1517844232326.png

11.上部メニュー「Nodes」を選択します。

AWS上に構築されたkubernetesクラスタの状況を確認できます。各クラスタ名をクリックするとリソース状況が可視化されます。

image.png

12.「KubeConfig File」ボタンをクリックします。

image.png

kubectlコマンドのconfigファイルをクリップボードにコピーできます。

image.png

kubectlコマンドを実行できるクライアントをローカルまたはサーバで構築します。今回はGCP上にGCEのインスタンス(Ubuntu 16.04 LTS)を1台用意します。

コマンド
$ curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl

$ chmod +x ./kubectl

$ sudo mv ./kubectl /usr/local/bin/kubectl

$ mkdir .kube

$ vim .kube/config
#クリップボードにコピーした内容をペーストして保存します。
:wq

$ kubectl get nodes
NAME               STATUS    ROLES         AGE       VERSION
aws-k8s-cluster1   Ready     etcd,master   26m       v1.8.5-rancher1
aws-k8s-cluster2   Ready     worker        23m       v1.8.5-rancher1
aws-k8s-cluster3   Ready     worker        25m       v1.8.5-rancher1

これで、kubectlコマンドでアプリケーションをデプロイすることが可能となります。

13.AWSのコンソールを確認します。

インスタンスが3台で来ていることが確認できます。

image.png

以上となりますが、AWS以外のAzure、DigitalOcean、Packet、vSphereも同様にRKEでkubernetesクラスタを構築できると思います。

参考資料

RKE(Rancher Kubernetes Engine)

続きを読む

Need Hostname change of AWS Instance

さらに表示: ec2 set hostname on boot, aws change hostname centos, ec2 set hostname from tag, aws cloud-init hostname, aws change hostname ubuntu, aws change public dns, aws change hostname windows, cloudformation set hostname, I need some change, i need a buyer so that i can rent the … 続きを読む

Amazon EC2インスタンス、ネットワーク帯域増大

拡張された帯域幅を活用するには、現行世代のEC2インスタンス上でENA(、Elastic Network Adapter)対応の最新AMI(Amazon マシンイメージ)を利用する必要があるとされている。AMIはAmazon Linux、Ubuntu 14.04/16.04、RHEL 7.4、SLES 12、Windows Server (2008 R2、2012、2012 R2、2016)、AWS … 続きを読む

Ubuntu 16.04 on AWSでリモートデスクトップを実現する(Macから接続)

前置き

Ubuntu 16.04 on AWSでリモートデスクトップ接続を実現しようとしたらハマったのでメモ。
Mac <-> UbuntuなのでVNCとかでやる方が普通そうなので需要あるかわかりませんが。。

以下のようなページを彷徨い、色々と試したが結果的にうまくリモートデスクトップが動かなかった。(ハマった箇所は色々あったが最後はssh接続は問題なくできているのにリモートデスクトップからだと「Connection Refused」で先に進めない。権限周りなどを色々と確認したがうまくいかなかった。)

https://cryptotrader.muragon.com/entry/56.html
http://akira.matrix.jp/archives/972

環境

サーバー
– Ubuntu Server 16.04 LTS (HVM), SSD Volume Type on AWS EC2

クライアント
– MacOSX 10.12.6

解決方法

しかし以下のページのコマンドで一発で行けた。ありがとう。
https://qiita.com/tmikada/items/be27df3affc56eeffd8b

インストール
$ sudo apt install xrdp xfce4 xfce4-goodies tightvncserver

ただし、以降の部分は実行したらうまくいかなかった(接続はされてるが、グレーの画面が表示されてデスクトップが表示されない。Xウィンドウの設定なんだと思うが、時間がないので調査は割愛)。

実行したらうまくいかなかった箇所
$ sudo vi /etc/xrdp/xrdp.ini
# 以下のように編集
---------
...
#. /etc/X11/Xsession
---------

実施した手順

最終的に実行した一連の流れは以下の通り。

xrdpのインストール
$ sudo apt install xrdp xfce4 xfce4-goodies tightvncserver
$ sudo service xrdp restart

AWSコンソールのセキュリティグループの設定(インバウンド)で以下を追加。

image.png

クライアントからログイン

Macのリモートデスクトップ接続で設定。

image.png

無事にデスクトップに接続。

image.png

続きを読む

AWS と Azure と自宅の PC で NVIDIA GPU Cloud (NGC) のコンテナを動かしてみた

こんにちは。エヌビディアの佐々木です。

NVIDIA GPU Cloud (NGC) というサービスをご存知でしょうか。端的に書けば 「NVIDIA が公開している Docker コンテナリポジトリ」 です。CaffeChainerTensorFlow 等の各種ディープラーニング フレームワークや、GAMESSGromacsLAMMPS といった HPC アプリケーションのコンテナが揃っており、もちろん GPU 実行に最適化されています。このコンテナを使えば、計算環境構築の手間をかなり削減することができます。

「Cloud」とあるので、クラウドで GPU を使うためのサービスと思われることがあるのですが、NGC は「コンテナを提供するクラウドサービス」であって、そのコンテナはクラウドに限らず、オンプレミスのコンピューターでも利用できます。

今のところ、コンテナの利用環境としてエヌビディアが正式にサポートするのは AWS の P3 インスタンス と、NVIDIA TITAN V を搭載するコンピューターのみですが、それ以外の環境でも Pascal 世代以降の GPU であれば動作するはずです。

というわけで、次のような3つの環境で試してみました。

  • AWS の P3 インスタンス (Tesla V100 搭載)
  • Microsoft Azure の ND インスタンス (Tesla P40 搭載)
  • 私の自宅 PC (GeForce GTX 1050 Ti 搭載)

※ 私の PC だけちょっと弱めですが、ロープロファイルのカードしか付かないんです…

NGC のアカウントを作る

まず、 NGC のサインアップページでアカウントを作成します。無料です。
2018-01-28_205005.png

NGC の API キーを生成する

アカウントができたらログインして、画面右上の “Get API Key” をクリックしてください。
2018-01-28_205552.png

次に、”Generate API Key” をクリックして API キーを生成します。これは後ほど NGC からコンテナを pull する際に使用します。
2018-01-28_210946.png

生成されたキーは必ずどこかに控えておいてください。”This is the only time your API Key will be displayed.” とあるとおり、二度と表示されません。
2018-01-28_211158.png

さて、アカウントと API Key ができたら、あとは実行環境の準備です。要件は次の通り。

  • Pascal 世代以降の GPU (と、そのドライバ)
  • NVIDIA Docker

では、AWS, Azure, 自宅 PC のそれぞれで試していきます。

実行環境を作る (AWS で)

AWS は NGC の正式サポート環境なので、準備も簡単です。NVIDIA Volta Deep Learning AMI という AMI をエヌビディアが提供していますので、これを使って P3 インスタンスを作れば OK です。ドライバも NVIDIA Docker もインストール済み。別途セットアップする必要はありません。(なお、G2, G3, P2 は、GPU が Kepler や Maxwell 世代なので NGC 非対応)

早速作ってみます。
2018-01-28_212822.png
東京は高いのでオレゴンで、インスタンスタイプは p3.2xlarge (Tesla V100 を1基搭載)を選びました。

インスタンスが動き始めたらログインしてみます。シェルのプロンプトが出る前にこんなことを聞いてきます。

Welcome to the NVIDIA Volta Deep Learning AMI. This environment is provided to
enable you to easily run the Deep Learning containers from the NGC Registry.
All of the documentation for how to use NGC and this AMI are found at
  http://docs.nvidia.com/deeplearning/ngc
Initializing nvidia-docker volume...

Please enter your NGC APIkey to login to the NGC Registry:

ここで、先ほど生成した API キーを入力(ペースト)します。

Logging into the NGC Registry at nvcr.io...Login Succeeded

こうなれば NGC 利用準備完了です。コンテナを動かす前に、 GPU を確認してみます。

$ nvidia-smi
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 384.81                 Driver Version: 384.81                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Tesla V100-SXM2...  On   | 00000000:00:1E.0 Off |                    0 |
| N/A   32C    P0    19W / 300W |     10MiB / 16152MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

本当に Tesla V100 SXM2 だ!テンション上がりますねー

では、コンテナを動かしてみます。NGC サイトの AWS のチュートリアルにある、PyTorch での MNIST 手書き文字認識が動作確認には手軽です。

$ nvidia-docker run --rm -ti nvcr.io/nvidia/pytorch:17.10
17.10: Pulling from nvidia/pytorch
f5c64a3438f6: Pull complete
51899d335aae: Pull complete
<略>

初回なのでいろいろとダウンロードする必要があり、少し時間がかかりますが、うまくコンテナが動き出しました。

=============
== PyTorch ==
=============

NVIDIA Release 17.10 (build 192702)

Container image Copyright (c) 2017, NVIDIA CORPORATION.  All rights reserved.

Copyright (c) 2016-     Facebook, Inc            (Adam Paszke)
Copyright (c) 2014-     Facebook, Inc            (Soumith Chintala)
Copyright (c) 2011-2014 Idiap Research Institute (Ronan Collobert)
Copyright (c) 2012-2014 Deepmind Technologies    (Koray Kavukcuoglu)
Copyright (c) 2011-2012 NEC Laboratories America (Koray Kavukcuoglu)
Copyright (c) 2011-2013 NYU                      (Clement Farabet)
Copyright (c) 2006-2010 NEC Laboratories America (Ronan Collobert, Leon Bottou, Iain Melvin, Jason Weston)
Copyright (c) 2006      Idiap Research Institute (Samy Bengio)
Copyright (c) 2001-2004 Idiap Research Institute (Ronan Collobert, Samy Bengio, Johnny Mariethoz)
All rights reserved.

Various files include modifications (c) NVIDIA CORPORATION.  All rights reserved.
NVIDIA modifications are covered by the license terms that apply to the underlying project or file.

NOTE: The SHMEM allocation limit is set to the default of 64MB.  This may be
   insufficient for PyTorch.  NVIDIA recommends the use of the following flags:
   nvidia-docker run --ipc=host ...

root@b3d044efeae1:/workspace#

コンテナの中で、サンプルスクリプトを動かしてみます。

root@b3d044efeae1:/workspace# cd /opt/pytorch/examples/mnist && python main.py
Train Epoch: 1 [0/60000 (0%)]   Loss: 2.390087
<中略>
Train Epoch: 10 [58880/60000 (98%)]     Loss: 0.272635
Train Epoch: 10 [59520/60000 (99%)]     Loss: 0.082086

Test set: Average loss: 0.0553, Accuracy: 9804/10000 (98%)

root@b3d044efeae1:/opt/pytorch/examples/mnist#

1分半ほどで10エポック完了しました。環境構築の手間いらずで、実に簡単ですね。

実行環境を作る (Azure で)

Microsoft Azure の仮想マシンで、Pascal 以降の GPU を搭載しているのは次の3種類です。

  • NCv2 (Tesla P100)
  • ND (Tesla P40)
  • NCv3 (Tesla V100: ただし、2018年1月時点ではプレビュー提供中)

今回は ND シリーズの一番小さいやつ(ND6s)をData Science Virtual Machine for Linux (Ubuntu)で作りました。これは AWS の NVIDIA Volta Deep Learning AMI のように、GPU ドライバや NVIDIA Docker があらかじめインストールされた仮想マシンイメージです。楽ちんです。

2018-01-28_221052.png

ログインしたら GPU を確認。確かに、Tesla P40 が搭載されていますね。こいつの GPU メモリサイズは 24GB と、P100 や V100 よりも大きいのです。

+-----------------------------------------------------------------------------+
| NVIDIA-SMI 384.111                Driver Version: 384.111                   |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Tesla P40           Off  | 00008B49:00:00.0 Off |                    0 |
| N/A   25C    P8    11W / 250W |     10MiB / 22912MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

では、動作確認を。Azure の場合、 AWS の NVIDIA Volta Deep Learning AMI のようにログイン時に NGC のキーを入力していませんので、まずは NGC へのログインが必要です。

下記コマンドの ‘$oauthtoken’ の部分は「環境に応じて適切に置き換えてください」という意味ではなく、「そのまま」入力してください。シェルに変数展開されないようにシングルクォートで括る必要があります。

$ docker login -u '$oauthtoken' --password-stdin nvcr.io <<< 'API キー'
Login Succeeded

あとは、AWS の場合と同じです。こちらでも PyTorch の MNIST を試してみました。同じことをやっても面白くありませんが、「同じものがどこでも動く」というのがコンテナの便利なところなので。

$ nvidia-docker run --rm -ti nvcr.io/nvidia/pytorch:17.10

=============
== PyTorch ==
=============

NVIDIA Release 17.10 (build 192702)

Container image Copyright (c) 2017, NVIDIA CORPORATION.  All rights reserved.

<略>

root@84835550d223:/opt/pytorch/examples/mnist# cd /opt/pytorch/examples/mnist && time python main.py

<略>

Train Epoch: 1 [0/60000 (0%)]   Loss: 2.390087
Train Epoch: 1 [640/60000 (1%)] Loss: 2.350225

<略>

Train Epoch: 10 [58880/60000 (98%)]     Loss: 0.307370
Train Epoch: 10 [59520/60000 (99%)]     Loss: 0.081178

Test set: Average loss: 0.0546, Accuracy: 9813/10000 (98%)

root@84835550d223:/opt/pytorch/examples/mnist#

(当たり前ですが) 無事に動きました。簡単ですね。

実行環境を作る (自宅の PC 等で)

さて、2種類のクラウドを試しましたが、次に自宅の PC でも試してみました。環境は次の通りです。

  • OS: Ubuntu 16.04.3 LTS
  • GPU: GeForce GTX 1050 Ti (Pascal 世代)

Deep Learning AMI のような便利なものはないので、GPUのドライバと NVIDIA Docker は自分でインストールする必要があります。

GPU ドライバのインストール

NVIDIA のドライバダウンロードページから、自分の GPU に対応したドライバのインストーラーをダウンロードしてインストールします。なお、NVIDIA Docker さえ動けば良いので、CUDA Toolkit のインストールは不要です。

NVIDIA Docker のインストール

NVIDIA Docker のインストールには前提条件として Docker が必要です。私はこちらのページを参考にして、Docker CE をインストールしました。実行したコマンドは次の通りです。

sudo apt update
sudo apt install apt-transport-https ca-certificates curl software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
sudo apt update
sudo apt install docker-ce

次に、 NVIDIA Docker をインストールします。こちらのページに手順がまとまっています。実行したコマンドは次の通りです。

curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add -
curl -s -L https://nvidia.github.io/nvidia-docker/ubuntu16.04/amd64/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list
sudo apt update

sudo apt install nvidia-docker2
sudo pkill -SIGHUP dockerd

あと、sudo なしで Docker を実行できるように、自分を docker グループに追加しました。

sudo gpasswd -a 自分 docker

コンテナの動作確認

「またか」という感じですが、PyTorch で MNIST してみます。

$ docker login -u '$oauthtoken' --password-stdin nvcr.io <<< 'API キー'
Login Succeeded
$ nvidia-docker run --rm -ti nvcr.io/nvidia/pytorch:17.10

=============
== PyTorch ==
=============

NVIDIA Release 17.10 (build 192702)

Container image Copyright (c) 2017, NVIDIA CORPORATION.  All rights reserved.

<略>

root@2dc683eff1b2:/opt/pytorch/examples/mnist# cd /opt/pytorch/examples/mnist && python main.py

<略>

Train Epoch: 1 [0/60000 (0%)]   Loss: 2.390087
Train Epoch: 1 [640/60000 (1%)] Loss: 2.350225

<略>

Train Epoch: 10 [58880/60000 (98%)]     Loss: 0.288593
Train Epoch: 10 [59520/60000 (99%)]     Loss: 0.084271

Test set: Average loss: 0.0529, Accuracy: 9821/10000 (98%)

root@2dc683eff1b2:/opt/pytorch/examples/mnist#

無事に動きました!

まとめ

NVIDIA GPU Cloud のコンテナを、2種のクラウドと自宅の PC で動かしてみました。
AWS と Azure は GPU ドライバと NVIDIA Docker インストール済みの仮想マシンイメージが使えるのでとても簡単。それ以外の環境でも、NVIDIA Docker の環境さえ作ってしまえば、あとは毎月更新される最新のコンテナを活用することで、環境構築とメンテナンスをかなり効率化できます。是非お試しを!

関連情報

続きを読む

Linux のログイン・ログオフ履歴を Cloudwatch Logs に送信する

サマリ

Linux のログイン/ログオフの履歴(だけ)を Cloudwatch Logs に送りたかった。
rsyslog から sshd のログだけ抽出して Cloudwatch Logs Agent で送った。できた。

要件

Linux へのログイン・ログオフの履歴を Cloudwatch Logs に保存する必要があり、Cloudwatch Logs Agent をインストールして /var/log/secure を Cloudwatch Logs に送信する。
ただし、トラフィック量の都合で secure 全て送るのはよろしくないのでいい感じに絞ったものを送信したい。

SSH ログイン時に出力されるログには2種類あり、

  1. sshd プロセスが出力する rsyslog

    • /var/log/secure
  2. login プロセス出力するログ達(バイナリ形式)
    • /var/log/wtmp (ログイン成功ログ)

      • last コマンドで表示、新しいものが上で並ぶ
    • /var/log/btmp (ログイン失敗ログ)
      • lastb コマンドで表示、新しいものが上で並ぶ

送信するにはテキストである必要があるため、

  1. rsyslog からうまいこと sshd プロセスのログだけを別ファイルにする

    • rsyslog で出力されたログをCloudwatch Logs Agent で送信する
  2. last/lastbコマンドを実行し、結果をログファイルに出力するシェルスクリプトを作成する。その際、時系列降順に直す必要がある。
    • cronで定期的に実行し、ログをCloudwatch Logs Agent で送信する

の2パターン考えられるが、楽そうな前者を試す。

設定手順

環境

  • Red Hat Enterprise Linux 7.4 (HVM)
  • awscli-cwlogs 1.4.4

SSHログの抽出

適当な EC2 インスタンスを起動。

要件としては、rsyslog の secure ログ /var/log/secure| grep 'sshd'したような結果が出力できればよさそう。そのほかの secure ログはいらない。

console
$ sudo cat /var/log/secure | grep 'sshd'
略
Jan 23 19:41:46 HOSTNAME sshd[5106]: Server listening on 0.0.0.0 port 22.
Jan 23 19:41:46 HOSTNAME sshd[5106]: Server listening on :: port 22.
Jan 23 20:40:54 HOSTNAME sshd[1976]: pam_unix(sshd:session): session closed for user ec2-user
Jan 23 20:47:46 HOSTNAME sshd[4914]: Accepted publickey for ec2-user from 10.0.0.2 port 61646 ssh2: RSA SHA256:xxx
Jan 23 20:47:46 HOSTNAME sshd[4914]: pam_unix(sshd:session): session opened for user ec2-user by (uid=0)
Jan 23 20:49:12 HOSTNAME sshd[4914]: pam_unix(sshd:session): session closed for user ec2-user

rsysgにはプロパティベース フィルタというものがあり、 :property, [!]compare-operation, "value"
programname でフィルタがかけられる。これを利用すれば特定のプロセスのログだけ別ファイルに出力することが可能。
なので rsyslog の設定をしていく。secure_sshd という新しいログファイルに sshd プロセスのログだけを出力する設定を追記。

/etc/rsyslog.conf
# sshd ログを別ファイルにも出力
:programname, isequal, "sshd" /var/log/secure_sshd
console
sudo service rsyslog restart

ログイン・ログオフしてから良い感じにログが出ていること確認できた。

console
$ sudo cat /var/log/secure_sshd
Jan 24 03:08:55 HOSTNAME sshd[9308]: Accepted publickey for ec2-user from 10.0.0.3 port 60196 ssh2: RSA SHA256:xxx
Jan 24 03:08:55 HOSTNAME sshd[9308]: pam_unix(sshd:session): session opened for user ec2-user by (uid=0)
Jan 24 03:09:14 HOSTNAME sshd[9308]: pam_unix(sshd:session): session closed for user ec2-user

Cloudwatch Agent 側設定

EC2インスタンスに CloudwatchLogs 用のポリシーをアタッチ。

Send2Cloudwatch
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "logs:DescribeLogStreams"
    ],
      "Resource": [
        "arn:aws:logs:*:*:*"
    ]
  }
 ]
}

パッケージ更新、awslogsインストール

console
sudo yum update -y
# ubuntu,centos,redhat はこう
curl https://s3.amazonaws.com/aws-cloudwatch/downloads/latest/awslogs-agent-setup.py -O
sudo python ./awslogs-agent-setup.py --region us-east-1
# Amazon Linux ならこっち
# sudo yum install awslogs

バージョン確認

console
$ /var/awslogs/bin/awslogs-version.sh
略
/etc/cron.d/awslogs_log_rotate version:
# Version: 1.4.3
CloudWatch Logs Plugin Version:
You are using pip version 6.1.1, however version 9.0.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
---
Metadata-Version: 1.1
Name: awscli-cwlogs
Version: 1.4.4
Summary: AWSCLI CloudWatch Logs plugin
Home-page: http://aws.amazon.com/cli/
Author: Amazon
Author-email: UNKNOWN
License: Amazon Software License
Location: /var/awslogs/lib/python2.7/site-packages
Requires: awscli, six, python-dateutil
AWS CLI Version

ログファイル送信設定、先ほどの secure_sshd を指定する

/var/awslogs/etc/awslogs.conf
# 元のmessageログ送信は今回使わないのでコメントアウト
# [/var/log/messages]
# datetime_format = %b %d %H:%M:%S
# file = /var/log/messages
# buffer_duration = 5000
# log_stream_name = {instance_id}
# initial_position = start_of_file
# log_group_name = /var/log/messages

# 普通にsecureログ送るならこう
# [/var/log/secure]
# datetime_format = %b %d %H:%M:%S
# file = /var/log/secure
# buffer_duration = 5000
# log_stream_name = {instance_id}
# initial_position = start_of_file
# log_group_name = /var/log/secure

[/var/log/secure_sshd]
datetime_format = %b %d %H:%M:%S
file = /var/log/secure_sshd
buffer_duration = 5000
log_stream_name = {instance_id}
initial_position = start_of_file
log_group_name = /var/log/secure_sshd

必要に応じてプロキシ設定

/var/awslogs/etc/proxy.conf
HTTP_PROXY=proxyserver:8080
HTTPS_PROXY=proxyserver:8080
NO_PROXY=

サービス再起動&起動設定

console
sudo service awslogs start
sudo chkconfig awslogs on

Logs への送信ログ確認するなら

console
sudo tail /var/log/awslogs.log

動きました

image.png

参考

CloudWatch Logs エージェントのリファレンス – Amazon CloudWatch ログ
クイックスタート: 実行中の EC2 Linux インスタンスに CloudWatch Logs エージェントをインストールして設定する – Amazon CloudWatch ログ
Linux環境設定/sshによる不正アクセスを確認する – Linuxと過ごす
Rsyslog – Wikinote
システム管理の基礎 syslogdの設定をマスターしよう:Linux管理者への道(3) – @IT
必読!ログファイルとディレクトリ | Think IT(シンクイット)

続きを読む

AWSのubuntuでbitcoind起動(testnet)

Ubuntuにbitcoindを入れよう

Bitcoin Core を AWS で動かしてみる

↑鬼参考になります。

ストレージが足りないので、mountしよう。

初期設定だと基本ストレージ足りませんので、ストレージ追加します。

EBSでストレージを追加、インスタンスにアタッチします。

その後

(xvdg)は各自切り替え

sudo su -
mkdir /data2
mount /dev/xvdg /data2

書き込みできるかチェック

mkdir -p /data2/test/file/to/ 
echo "this is text file" > /data2/test/file/to/test.txt
cat /data2/test/file/to/test.txt
this is text file

自動マウントの設定

このままだとEC2インスタンスをSTOP等をした際に、マウントが外れてしまうので、自動マウントするように設定しておく。
意外と忘れがち。
以下を/etc/fstabの末尾に追加する。

/dev/xvdg /data2 ext4 defaults 1 1

bitcoindを起動

まずは、bitcoin.confのdatadirで/data2(さっき指定したディレクトリ)を指定

bitcoin.conf
rpcuser=root
rpcpassword=bitroot

HOST=localhost

server=1
txindex=1

rpcport=18332
testnet=3

datadir=/data2

ディレクトリを/usr/binにうつして、bitcoidを起動しよう

cd /usr/bin
./bitcoind -testnet -daemon

これで起動してもいいけど、最初のうちはコンソール出力したほうがいいかも。

./bitcoind -testnet -printtoconsole

 結果

00000 in blk00004.dat
2018-01-23 15:13:40 UpdateTip: new best=000000000bf873bfec3b2ed7fe9feaca4d119eb6d584cdcd2387c27460f6e388 height=207360 version=0x00000002 log2_work=58.246667 tx=1290276 date='2014-03-23 05:51:29' progress=0.076149 cache=311.8MiB(2239277txo)
2018-01-23 15:13:40 UpdateTip: new
...
best=00000000000b6365327c7e408c22ea27ae43199c9813bb876ad82925859b0b31 height=207437 version=0x00000002 log2_work=58.250024 tx=1291019 date='2014-03-23 07:21:58' progress=0.076193 cache=316.7MiB(2279164txo)
2018-01-23 15:13:41 UpdateTip: new 
...

そりゃストレージ死にますな。
僕の場合、デフォルトで650MiBくらいに到達したタイミングで

Disk space is low!

とか言われました。ですよねー。

参考

続きを読む

Ubuntu on AWSに軽量デスクトップLXDEとxrdpを使ってリモート接続してみた | Developers.IO

Ubuntu on AWSに軽量デスクトップLXDEとxrdpを使ってリモート接続してみた | Developers.IO. 18 users テクノロジー 記事元: クラスメソッド発のAWS/iOS/Android技術者必読メディア | Developers.IO … 続きを読む

Ubuntu on AWSに軽量デスクトップLXDEを使ってリモート接続してみた

LXDEをリモートのUbuntuで使うケースでは、一旦ターミナルでLXDE内のlxdmというコンポーネントを起動させてxrdpへリモートデスクトップでつなぎに行くという(ないしはそういった起動スクリプトを作る)インストラクションをよく見かけますが、サービスを手で作ることなくターミナルなしでAWSにつなぎに行ける簡単な方法がある … 続きを読む

カテゴリー 未分類 | タグ