もう、タイトルが全てでありますー。
以前に「Azure DC/OSに、もう1つノード追加したいな！」ってなって、AzureもDC/OSも初心者の僕は「はて？どうやるんだろう？」ってなったのだった。そういえばAgentノードのインスタンスはScaleSetsっていうリソースなんだけど、名前から察するに増やせそうだよな、って見てみたら増やせたのであった。
例えば、プライベートノード用のScaleSetsにインスタンスが3つある状態で↓
Scalingを選んで編集↓
4つにして保存↓
4つになった(∩´∀｀)∩ﾜｰｲ↓
って、以前はGUIからポチポチするのなかったから、なんかテンプレートみたいなのでやったんだけど、見落としてただけなのか、最近追加されたのかどっちか分かんないけど、どっちにしても今はGUIからポチポチできるみたいね。便利。
Azure DC/OS は、SSHトンネルを作って、GUIとかAPIとかで操作するのが基本ぽい。
SSHで中に入るのは非推奨って書いてる。
SSH セッションは、クラスター管理システムとの間で作成することができます。 ただし、これは推奨されません。 管理システムで直接作業すると、構成を意図せず変更してしまうおそれがあります。
確かにそうだなー。でも、勉強中の今は、つなぎたいときもある。「どんな感じで動いてるのか知りたいなー？」ってときとか。なので、忘れないうちにメモしとく。
今回の記事用にsandboxっていう名前でDC/OSを立ち上げといた。
$ MASTER_FQDN=sandboxmgmt.japanwest.cloudapp.azure.com
トンネルつないだ状態でローカルからDC/OS CLIを叩くと、叩ける。便利。
$ sudo ssh -L 80:localhost:80 -f -N azureuser@${MASTER_FQDN} -p 2200
$ dcos auth login
Login successful!
$ dcos marathon app list
ID MEM CPUS TASKS HEALTH DEPLOYMENT CONTAINER CMD
/first-app 128 1 0/1 --- scale DOCKER None
「ちょっと中がどんな感じなのか入って見てみたいなー」と思ったので、ここを読みながら、ふむふむ。
こうか
$ dcos node ssh --master-proxy --leader
つながらない。。。(´；ω；｀)ﾌﾞﾜｯ
直接つないでみるとつながる。
$ sudo ssh azureuser@${MASTER_FQDN} -p 2200
Welcome to Ubuntu 16.04 LTS (GNU/Linux 4.4.0-28-generic x86_64)
* Documentation: https://help.ubuntu.com/
Get cloud support with Ubuntu Advantage Cloud Guest:
http://www.ubuntu.com/business/services/cloud
78 packages can be updated.
0 updates are security updates.
*** System restart required ***
Last login: Thu Dec 15 23:11:17 2016 from
azureuser@dcos-master:~$
マスターノードにはつながったから、次はエージェントノードにつなぎたいな。マスターからエージェントに入ればいいのかな。じゃ、一回マスターから出て、こんな感じで繋げばいけるかな。
$ sudo ssh -A azureuser@${MASTER_FQDN} -p 2200
azureuser@dcos-master:~$ ssh azureuser@10.32.0.5
azureuser@dcos-agent-private:~$あぁ、つながった。(∩´∀｀)∩ﾜｰｲ
ところで Azure DC/OSの場合、ローカルからだと使える機能と使えない機能があるみたい？だから、マスターノードにDC/OS CLI入れてみよっかな。
azureuser@dcos-master:~$ curl -O https://downloads.dcos.io/binaries/cli/linux/x86-64/dcos-1.8/dcos azureuser@dcos-master:~$ chmod +x dcos azureuser@dcos-master:~$ ./dcos config set core.dcos_url http://localhost [core.dcos_url]: set to 'http://localhost' azureuser@dcos-master:~$ ./dcos auth login Login successful!
で、AgentにつなぐときはMesos IDをとってきて
こうかな
azureuser@dcos-master:~$ ./dcos node ssh --user=azureuser --mesos-id=18a6d7ad-d8a9-4832-a2ed-51ca8e0c3946-S0 azureuser@dcos-agent-public:~$
つながった。dockerコマンドでも叩いてみるか。
azureuser@dcos-agent-public:~$ sudo docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 3f85c267f8a4 nginx "nginx -g 'daemon off" 32 minutes ago Up 32 minutes mesos-18a6d7ad-d8a9-4832-a2ed-51ca8e0c3946-S0.169cb095-d115-4519-a51a-a01313e2fb2a
見れた。良かった。
ノードに入ることができて良かった。んで、CLIをマスターノードに入れとくのもついでにやってみたけど、悪くないかもなぁ。
「Azure の DC/OS が使いやすくなった」っていうより「Azure の使ってる DC/OS のバージョンが上がったから使いやすくなってた」って感じなのかな。DC/OS GUI のダッシュボードはこんな画面で
今僕は、Publicノード1つ、Privateノード3つの合計4ノードを使ってるんだけど、その全部のリソースを1台のマシンのように扱う事ができる感じ。CPU8個、メモリ23GB、Disk25GB。
これまではアプリをデプロイする時には DC/OS GUI とは別に Marathon GUI を開いて操作してたんよね。いや、むしろ DC/OS GUI は開かずに Marathon GUI だけ開いてたかも。
それが気づくと DC/OS GUI の「Service」ってところに Marathon が一体化してた。
Marthon GUI にある機能は全部あるっぽい。しかも見た目が好きな感じ。これは詳細画面↓
ログも画面上で tail -f っぽい動きする。
これまでは「DC/OS って言っても、結局 Mesos と Marathon じゃん」って感じだったんだけど、画面見ても分かる通り Services と Jobs というところで Marathon と Metronome が一体化してて、いよいよ DC/OS 感が出てきたのかなー。ちな、これまで通りに Marthon GUI を使いたい人は使えます。APIについても勉強しなきゃなー。
参照:
僕はSpring Cloudに関して、Kennyのこのリポジトリを参照しまくってるんだけど。
Dockerの設定が入ってるので参考にした。
ここでやっといたよ。
これだけ。
例えば僕のリポジトリの config-service ならここ
https://github.com/bufferings/msa/blob/master/config-service/pom.xml#L61-L77
<plugin> <groupId>com.spotify</groupId> <artifactId>docker-maven-plugin</artifactId> <version>0.4.13</version> <configuration> <useConfigFile>true</useConfigFile> <imageName>${docker.image.prefix}/${project.artifactId}</imageName> <dockerDirectory>${basedir}/src/main/docker</dockerDirectory> <resources> <resource> <targetPath>/</targetPath> <directory>${project.build.directory}</directory> <include>${project.build.finalName}.jar</include> </resource> </resources> </configuration> </plugin>
spotifyのdocker-maven-plugin使ってるす。
useConfigFile についてはここに書いてる。
https://github.com/spotify/docker-maven-plugin#using-docker-config-file-for-authentication
Another option to authenticate with private repositories is using dockers ~/.docker/config.json.
ログインしといたら ~/.docker/config.json を使ってくれるってことね。
${docker.image.prefix}プロパティを bufferings1 で定義しといた。
<properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding> <java.version>1.8</java.version> <docker.image.prefix>bufferings1</docker.image.prefix> </properties>
finalName もDockerfileでプロジェクト毎にとか、バージョンが変わる毎に内容を書き換えるの面倒だったので finalName を固定しといた。僕は今回特に finalName を使ってないから別にいっかなって思って。
<finalName>app</finalName>
dockerDirectory で指定した src/main/docker の下に Dockerfile を置いとく。
FROM anapsix/alpine-java:8 VOLUME /tmp ADD app.jar app.jar RUN bash -c 'touch /app.jar' ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]
ここを参考にして
https://github.com/spotify/docker-maven-plugin#usage
docker login したあとに、こうしたら
mvn clean package docker:build -DpushImage
Docker Hub に push される。(∩´∀｀)∩ﾜｰｲ
.travis.yml.travis.yml にこんな感じで書いといた
sudo: required language: java jdk: - oraclejdk8 cache: directories: - $HOME/.m2 services: - docker script: - docker login -e="$DOCKER_EMAIL" -u="$DOCKER_USERNAME" -p="$DOCKER_PASSWORD" - mvn -f auth-service clean package docker:build -DpushImage - mvn -f config-service clean package docker:build -DpushImage - mvn -f discovery-service clean package docker:build -DpushImage - mvn -f edge-service clean package docker:build -DpushImage - mvn -f kaiten-sushi-web clean package docker:build -DpushImage - mvn -f user-service clean package docker:build -DpushImage
https://hub.docker.com/u/bufferings1
(∩´∀｀)∩ﾜｰｲ
昨日の朝、ぼーっとしてたらこんな記事があったので
Prometheusっていうモニタリングツールがあるのかぁと思って。
触ってみようかなと思ったのでした。
Dockerで動くとあんまり何も考えなくていいなぁって思ってたら、ちゃんとあった( Installing | Prometheus )。(∩´∀｀)∩ﾜｰｲ
docker run -p 9090:9090 prom/prometheus
で、9090にアクセスしたらとりあえず動いてる。
さっきのは起動しただけで何も情報がないので、実際に監視してみるとどんな感じになるのか。サンプルとして自分自身を監視できるみたいなのでやってみよう。
Getting started を読みながらprometheus.ymlってファイルを作って
global: scrape_interval: 15s # By default, scrape targets every 15 seconds. # Attach these labels to any time series or alerts when communicating with # external systems (federation, remote storage, Alertmanager). external_labels: monitor: 'codelab-monitor' # A scrape configuration containing exactly one endpoint to scrape: # Here it's Prometheus itself. scrape_configs: # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config. - job_name: 'prometheus' # Override the global default and scrape targets from this job every 5 seconds. scrape_interval: 5s static_configs: - targets: ['localhost:9090']
その設定ファイルをDockerイメージに渡して起動
docker run -p 9090:9090 -v $(pwd)/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus
なんか色々出てくるようになったので適当に選んでみる
なんかいい気分だ
このままじゃあんまりやる気出ないのでgrafanaにできるっぽいのでしてみよう。
ここを参考にした↓
Monitoring with Prometheus, Grafana & Docker Part 1 — finestructure
こんな感じでdocker-composeファイル作れば良さそうかな。
version: '2' services: prometheus: image: prom/prometheus volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml expose: - "9090" grafana: image: grafana/grafana ports: - "3000:3000"
で docker-compose up して 3000 にアクセス。起動してた。
データソースをPrometheusにする必要があるっぽいので
こんな感じ。Nameは適当。Urlはcomposeファイルに書いたサービス名ね。
でダッシュボードを作るっぽい
Graphを選んで
最初はサンプルが表示されてるんだけど、パネルをクリックしてでてきたポップアップからEdit
メトリクスの部分でさっきのデータソース(ここでは My prometheus)を選んで、適当にクエリを書く
とグラフがでてきた。(∩´∀｀)∩ﾜｰｲ
ちょこちょこ触ってみよっと。
これまた楽ちんだった。
JJUG CCCの発表用に作ったデモアプリ( #jjug_ccc DDDとMicroservicesについて喋ってきましたー(∩´∀｀)∩ - Mitsuyuki.Shiiba )で、Doma2を使ってみた。Doma1は以前に使ったことあるけどDoma2は初めて。っても、Doma2の機能の話じゃなくて、Doma2をSpring BootとMavenとEclipseで使ってみたよ。って話ね。
Spring Bootのアプリにこれを追加すればいいだけ。
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-jdbc</artifactId> </dependency> <dependency> <groupId>org.seasar.doma.boot</groupId> <artifactId>doma-spring-boot-starter</artifactId> <version>1.1.0</version> </dependency>
Doma は Annotation Processor を使ってるから、pomのビルド設定を書くのが面倒くさかったんだけど、doma-spring-boot-starterが良いようにやってくれてるっぽい！素敵だ。
僕はSTSを使ったからMaven周りのプラグインが最初から入ってるんだけど、ここに m2e を追加で入れておく。で、プロジェクトをインポートすると、自動的に Annotation Processor が設定される。素敵だ。
SpringのTransactionalアノテーションが特に何も考えなくても使える。素敵だ。(パッケージプライベートなメソッドにつけててトランザクションかからなくて？？？ってなってたのは内緒)
h2を使ったので application.yml に doma.dialect: h2 をつけといたらDialectがh2になった。素敵だ。
SQLファイルとDaoの間を行ったり来たりするプラグイン。入れとくと便利。
http://doma.readthedocs.io/ja/stable/getting-started/#eclipse-doma-tools
特に何も考えずにSQLファイルを src/main/java/META-INF の下に入れてて。Eclipseで動かすときは問題なかったんだけど、Mavenでビルドしようとすると「SQLファイルが見つからない」って怒られて。「はて？」ってなってたんだけど、これ src/main/resources/META-INF の下に入れなきゃいけないっぽい。ま、SQLファイルなんだし、そのほうが自然だな。
全然関係ないけど、Entity クラスのフィールドとして LocalDateTime が何も考えずに使えるところに幸せを感じた。
Welcome to Doma — Doma 2.0 ドキュメント
Spring Boot + Doma2を使おう - BLOG.IK.AM
好き嫌いの分かれるLombok。僕は好き。
使い始めは @Data とか使って「便利！」とか思ってたけど。最近は使わなくなった。というのも、DDDスタイル好きなのでモデルでは setter を公開しなくて、なので、使うのはこの3つくらいかな。
@Getter @EqualsAndHashCode @ToString
@Accessors にfluentの設定を入れると例えば firstName フィールドに対する getter が firstName() になるので、こっちの方が好みではあるんだけど、getXxxの方がJSON関係とか色んなライブラリで使いやすいから普通に getter で使う方が良さそうかな。あと、単なるDTOだったら使うかな？とも思ったんだけど結局 public フィールド使うから @Data 使わなくて @EqualsAndHashCode と @ToString を使うくらい。使いすぎには注意したい。
ただ、Lombokはアノテーションプロセッサーを使ってることもあり。ビルド周りの設定が面倒、特にMavenの設定。すぐ忘れる。って気持ちだったんだけど。そこはさすがSpring Boot。楽だった。pomに↓の依存関係を追加するだけ。親pomがいい具合にやってくれてるんだろうなぁ。
<dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <scope>provided</scope> </dependency>
Eclipseの方は普通にlombokをインストールすればよくて
java -jar lombok.jar
こんな感じになる
Spring Boot使うとLombokも簡単に使えて良いなー。