Java On Docker

Preview:

Citation preview

Docker On A.*

マルチクラウドに備えた Java on Dockerの手引き

自己紹介 高橋裕也 株式会社オープンストリーム  ソリューションアーキテクト OCaml 、 Scala 、 Java 、 JavaSc

ript など derui@github

今回のゴール

Java アプリのマルチクラウド対応での課題と解決策を知る

Agenda マルチクラウドのきっかけ Java の課題と Docker 開発フローの課題と解決案 おさらい

Agenda マルチクラウドのきっかけ Java の課題と Docker 開発フローの課題と解決案 おさらい

マルチクラウドのきっかけなぜ、マルチクラウドか?

マルチクラウドのきっかけ1. クラウドの大規模障害Google Cloud Platform で世界規模の障害発生( 2016/4 )

マルチクラウドのきっかけ2. コストクラウド間の機能差よりもコスト差に注目

マルチクラウドのきっかけ3. 政治的理由突然の心変わりや諸事情

転ばぬ先の杖

突然のマルチクラウド対応でも安心して開発したい

Agenda マルチクラウドのきっかけ Java の課題と Docker 開発フローの課題と解決案 おさらい

Java といえば

Write Once,Run Anywhere

マルチクラウドでの課題

Java がRun Anywhere

とは言えないこと

Run Anywhere の実際

Run on any JRE ではない

利用するライブラリや言語機能によっては動かない

Run Anywhere 実現の課題

環境単位でのポータビリティ

環境レベルのポータビリティ解決策:

Docker

Docker とは コンテナ実装の一つ

コンテナとは仮想化の一種 OS 仮想化より速い

コンテナイメージが簡単に作成・共有できる

OS 仮想化

OS 仮想化とコンテナ仮想化

ハードウェア

OS OS

アプリ アプリ

ハイパーバイザ

コンテナ仮想化

ハードウェア

OS

アプリ アプリコンテ

ナ コンテナ

Docker のメリット

1. 環境をポータブルに

JRE や周辺環境を含めたコンテナイメージを作成できる

Docker のメリット

2. 本番環境=開発環境

どこでも同じコンテナイメージが動く

Java + Docker JRE 管理が一元化 ローカルと本番で全く

同じイメージを使える

Agenda マルチクラウドのきっかけ Java の課題と Docker 開発フローの課題と解決案 おさらい

Java + Docker 開発フロー(案)

開発フローの前提

Vagrant でゲストを管理 ホストは Windows/Mac ゲストは Linux

Docker 自体は Linux でしか動かない

Vagrant とは

開発環境の管理を容易にするツール

ホストとゲストのディレクトリ同期を提供 共有フォルダ

Java + Docker 開発の課題

1. アプリの構成2. イメージサイズ3. 開発のテンポ4. イメージの共有

Java + Docker 開発の課題

1. アプリの構成2. イメージサイズ3. 開発のテンポ4. イメージの共有

課題 1 :アプリの構成

サーブレットコンテナの設定管理が煩雑

サーブレットコンテナのデメリット

設定変更=コンテナイメージの再ビルド

コンテナイメージの仕組み

ベースイメージ

差分

ベースイメージ

差分

差分

コンテナイメージ Aコンテナイメージ B

サーブレットコンテナのデメリット

イメージサイズ=大起動時間=長

課題 1 :アプリの構成

解決案:サーブレットコンテナをコンテナ内で使わない

フレームワークで解決

WAR 不要のフレームワーク Play! Framework Spark Framework

コンテナ同梱のフレームワーク Spring Boot

Java + Docker 開発フロー(改1 )

Java + Docker 開発フロー(改1 )

Java + Docker 開発の課題

1. アプリの構成2. イメージサイズ3. 開発のテンポ4. イメージの共有

課題 2 :イメージサイズ

イメージサイズ→大=

ビルド時間→長

大きいイメージのデメリット

ストレージ占有域の拡大

大きいイメージのデメリット

アップロードの時間→長ダウンロードの時間→長

課題 2 :イメージサイズ

解決案:より小さいベースイメージを使う

小さいベースイメージ

Alpine( アルパイン )イメージ

Alpine イメージをベースに

ベースイメージ 容量 ビルド時間Java8 (公式) 643MiB 32 秒Java8 ( Alpine )

145MiB

22 秒

Java + Docker 開発フロー(改2 )

Java + Docker 開発フロー(改2 )

Java + Docker 開発の課題

1. アプリの構成2. イメージサイズ3. 開発のテンポ4. イメージの共有

課題 3 :開発のテンポが悪い

JAR ビルドの度にイメージの再ビルドが必要

ビルドが必要な理由

イメージの中のJAR だけを更新できない

課題 3 :開発のテンポ

解決案:

ボリュームマウント+

自動コンテナ再起動

ボリュームマウントとはLinux

ボリュームマウントを使う

Vagrant の共有フォルダを コンテナにマウント ホスト側の変更= コンテナ側の変更

自動コンテナ再起動

ビルドツールを利用ビルド完了時点で

ゲスト側のコンテナを再起動

自動コンテナ再起動 (Gradle 版 )buildscript { repositories { mavenCentral() jcenter() } dependencies { classpath 'org.hidetake:gradle-ssh-plugin:0.4.5' classpath 'com.bluepapa32:gradle-watch-plugin:0.1.5' }}

apply plugin: 'com.bluepapa32.watch'watch { java { files files('src/main/java') tasks 'compileJava' }

cls { files files("${buildDir}/classes") tasks 'restart' }}

apply plugin: 'org.hidetake.ssh'

// gradle-ssh-plugin で利用する接続先の設定remotes { vagrant { host = '127.0.0.1' port = 2222 user = 'vagrant' password = 'vagrant' knownHosts = allowAnyHosts }}

// ssh 経由でコンテナ再起動task restart << { ssh.run { session(remotes.vagrant) { executeSudo 'docker stop app' executeSudo 'docker start app' } }}

Java + Docker 開発フロー(改3 )

Java + Docker 開発フロー(改3 )

Java + Docker 開発の課題

1. アプリの構成2. イメージサイズ3. 開発のテンポ4. イメージの共有

課題 4 :イメージの共有

作ったイメージを開発チームのみで共有したい

Docker イメージ共有の基本

Docker 公式の共有サイト( Docker Hub )では基本的に全て Public

Docker イメージ共有の基本

Private に共有したい場合いくつかの選択肢から選ぶ

Docker イメージの共有方式

Docker Hub の Private 組織単位では有料

Private Docker Registry

課題 4 :イメージの共有

解決案:Private Docker Registryを使う

Docker Registry とは

Docker Hub のバックエンド Docker Registry の

コンテナイメージが提供されている

Docker Registry の特徴

コンテナイメージを保存するストレージを選べるローカルストレージクラウドストレージ

Private Docker Registry の定義

クラウドストレージを使ってDocker Registry をローカル環境で動かす

Private Docker Registry のメリット

クラウドストレージを使うので、 容量に脅かされない

ローカルで動かすので、サーバー不要

Java + Docker 開発フロー(最終)

Java + Docker 開発フロー(最終)

クラウドへのデプロイ (GCP)

クラウドへのデプロイ(AWS)

実例: Dockerfile と起動

FROM localhost:5000/java8MAINTAINER Yuya Takahashi

# Expose PORT EXPOSE 8080

# Copy the app into the image.RUN mkdir /opt/playapp

ADD ./target/universal/stage /opt/playapp

Play2 の場合

コンテナ起動例docker run –d \ -v /vagrant/app/target/universal/stage:/opt/playapp \ -p 8080:8080 backend

# Start appCMD bash /opt/playapp/bin/backend \ -Dhttp.port=8080 \ -DLOG_HOME="/opt/playapp" \ -Dconfig.resource=application-prod.conf \ -Dlogger.resource=logback-prod.xml

Docker Registry の設定例version: 0.1log: level: info formatter: text fields: service: registry environment: stagingstorage: s3: region: ap-northeast-1 bucket: company-bucket v4auth: true rootdirectory: /registry delete: enabled: true cache: blobdescriptor: inmemory

maintenance: uploadpurging: enabled: true age: 168h interval: 24h dryrun: false readonly: enabled: falsehttp: addr: :5000 secret: asecretforlocaldevelopment relativeurls: false headers: X-Content-Type-Options: [nosniff]

Agenda マルチクラウドのきっかけ Java の課題と Docker 開発フローの課題と解決案 おさらい

今日のおさらい

マルチクラウド対応はいつ来るかわからない 慌てる前に Docker 対応 環境レベルのポータビリティ

今日のおさらい

Java + Docker 環境に左右されない開発を実現 本番と同じ環境で開発できる ステージングなどの区別がいらな

Java + Docker で上司やクライアントに

振り回されない開発を

OPST BIGDATA PLATFORM

ご清聴ありがとうございました!

Recommended