IBM Index 2018 Conference Workshop: Modernizing Traditional Java App's with Docker

Discover. Collaborate. Deploy.
Modernizing
Traditional Java Apps
with Docker
Eric Smalling
Solution Architect at Docker Inc
smalls@docker.com
@ericsmalling

2
Who Am I?
● Eric Smalling
○ Solution Architect
Docker Customer Success Team
● ~25 years in software development,
architecture, version control admin, etc…
● ~10 years in build & test automation
● Docker user since pre-1.0 days
● Java developer since 1.1.x days

Workshop Agenda
Section 1: Docker 101 (50 minutes)
What is Docker / What is Docker Not
Basic Docker Commands
Building Images & Running Containers
(Hands-on)
Anatomy of images and containers
Volumes
Break
Section 2: MTA with Java (60 minutes)
Challenges
How Docker applies to these
challenges
Moving a legacy Java app into Docker
(Hands-on)
Sustainably modernizing applications
(Hands-on)
Break
Hands on exercises mixed throughout
Section 3: Going to production with
your “Dockerized” apps (20 minutes)
Automated Health Checks
Warnings about running JVM’s in
containers
Logging
Troubleshooting
App Configuration
Docker Secrets
CI/CD with Docker EE

Section 1: Docker 101
A quick overview of Docker

5
Docker containers are NOT VMs
• Easy connection to make
• Fundamentally different architectures
• Fundamentally different benefits

• Standardized packaging for
software and dependencies
• Isolate apps from each other
• Share the same OS kernel
• Works for all major Linux
distributions
• Containers native to Windows
Server 2016
What is a container?

9
They’re different, not mutually exclusive

Docker Image
The basis of a Docker container. Represents a full application
Some Docker vocabulary
Docker Engine
Creates, ships and runs Docker containers deployable on a physical
or virtual, host locally, in a datacenter or cloud service provider
Docker Container
The standard unit in which the application service resides and
executes
Registry Service (Docker Hub or Docker Trusted Registry)
Cloud or server based storage and distribution service for your
images

Building a Docker image
The docker client command
“build” = build an image
“-t” = apply a name and optional build
Image name and optional tag
Path to build context and Dockerfile

Running the image in a container
The docker client command
“run” = start a container
“--rm” = delete container when it exits
“-t” = run with a tty (for console i/o)
“-i” = run in interactive mode
These often are used in combination like this
Image name and optional tag

13
Before we start hands-on labs
https://goto.docker.com/IBM-Index-PWD.html
Make sure you can get to this site:

Hands-on exercise #1: The basics
1. Open “Play With Docker” in your browser: https://goto.docker.com/IBM-Index-PWD.html
2. Optional: Run “apt-get update” & “apt-get install nano”
(skip this if you like vim)
3. Create a Dockerfile in the current directory with the following content:
FROM ubuntu:16.04
RUN apt-get update -y
#Install JDK
RUN apt-get install -y default-jdk
CMD java -version
4. Run “docker build -t myapp:1 .” to build your image and tag it. There will be a lot of output
ending in something like:
Successfully built b3fec78836f9
Successfully tagged myapp:1
5. Run “docker run --rm -ti myapp:1” to run your container, you should see output similar to:
openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)

Hands-on exercise #1: Results
The Docker Image
Take a look at the image you just created:
$ docker image ls myapp
REPOSITORY TAG IMAGE ID CREATED SIZE
myapp 1 33c38ae31747 21 hours ago 498MB

Hands-on exercise #1: Results
Docker Image Layers
$ docker image history myapp:1
IMAGE CREATED CREATED BY SIZE COMMENT
33c38ae31747 21 hours ago /bin/sh -c #(nop) CMD ["/bin/sh" "-c" "java… 0B
334a9f1fdb99 21 hours ago /bin/sh -c apt-get install -y default-jdk 347MB
0786492ffc8b 21 hours ago /bin/sh -c apt-get update -y 39.6MB
0458a4468cbc 2 weeks ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0B
<missing> 2 weeks ago /bin/sh -c mkdir -p /run/systemd && echo 'do… 7B
<missing> 2 weeks ago /bin/sh -c sed -i 's/^#s*(deb.*universe)$… 2.76kB
<missing> 2 weeks ago /bin/sh -c rm -rf /var/lib/apt/lists/* 0B
<missing> 2 weeks ago /bin/sh -c set -xe && echo '#!/bin/sh' > /… 745B
<missing> 2 weeks ago /bin/sh -c #(nop) ADD file:a3344b835ea6fdc56… 112MB
ubuntu:16.04
(consists of its own layers, pulled from registry)
apt-get update -y
apt-get install -y default-jdk
<meta: CMD= “java -version”/>

Docker File System
Images, Layers & Containers
● Logical file system by grouping different file system
primitives into branches (directories, file systems,
subvolumes, snapshots)
● Each branch represents a layer in a Docker image
● Allows images to be constructed / deconstructed as
needed vs. a huge monolithic image (ala traditional virtual
machines)
● When a container is started a writeable layer is added to
the “top” of the file system

Hands-on exercise #1.5: Optimizing
1. Edit your Dockerfile to match the following content:
FROM openjdk:8-alpine
CMD java -version
2. Run “docker build -t myapp:1.5 .” to build your image and tag it. There will be a lot of output
ending in something like:
Successfully built 14840ef6b00e
Successfully tagged myapp:1.5
3. Run “docker run --rm -ti myapp:1.5” to run your container, you should see output similar to:
openjdk version "1.8.0_151"
OpenJDK Runtime Environment (IcedTea 3.6.0) (Alpine 8.151.12-r0)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)

Hands-on exercise #1.5: Results
Compare Docker Images
Now, compare the two images:
$ docker image ls myapp
REPOSITORY TAG IMAGE ID CREATED SIZE
myapp 1.5 14840ef6b00e 9 minutes ago 102MB
myapp 1 33c38ae31747 21 hours ago 498MB

Hands-on exercise #1.5: Results
Optimized Docker Image Layers
$ docker image history myapp:1.5
IMAGE CREATED CREATED BY SIZE COMMENT
14840ef6b00e 12 minutes ago /bin/sh -c #(nop) CMD ["/bin/sh" "-c" "java… 0B
224765a6bdbe 4 weeks ago /bin/sh -c set -x && apk add --no-cache o… 97.4MB
<missing> 4 weeks ago /bin/sh -c #(nop) ENV JAVA_ALPINE_VERSION=8… 0B
<missing> 4 weeks ago /bin/sh -c #(nop) ENV JAVA_VERSION=8u151 0B
<missing> 4 weeks ago /bin/sh -c #(nop) ENV PATH=/usr/local/sbin:… 0B
<missing> 4 weeks ago /bin/sh -c #(nop) ENV JAVA_HOME=/usr/lib/jv… 0B
<missing> 4 weeks ago /bin/sh -c { echo '#!/bin/sh'; echo 'set… 87B
<missing> 4 weeks ago /bin/sh -c #(nop) ENV LANG=C.UTF-8 0B
<missing> 4 weeks ago /bin/sh -c #(nop) CMD ["/bin/sh"] 0B
<missing> 4 weeks ago /bin/sh -c #(nop) ADD file:093f0723fa46f6cdb… 4.15MB
openjdk:8-alpine
(consists of its own layers, pulled from registry)
<meta: CMD= “java version”/> 0B
102MB
14840ef6b00e
224765a6bdbe

Docker File System
Containers & Copy on Write
● Super efficient:
Sub second instantiation times for containers
New container can take <1 Mb of space
● Containers appears to be a copy of the original image
But, it is really just a link to the original shared image
● If someone writes a change to the file system, a copy of
the affected file/directory is “copied up”

Running containers
One Container
Kernel
Ubuntu Linux
apt-get update -u
<meta: CMD= “java version”/>
R/W Layer

Running containers
Two containers from same image
Kernel
Ubuntu Linux
apt-get update -u
R/W Layer R/W Layer

Running containers
Three containers from same image
Kernel
Ubuntu Linux
apt-get update -u
R/W Layer R/W Layer R/W Layer

Dockerfile - Linux + Java
Example: Initial state

Example: Optimization step 1

Example: Optimization step 2

Example: Fully Optimized

Docker File System
What about data persistence?
● Volumes allow you to specify a directory in the container
that exists outside of the docker file system structure
● Can be used to share (and persist) data between
containers
● Directory persists after the container is deleted
Unless you explicitly delete it
● Can be created in a Dockerfile or via CLI

Section 2: MTA
Modernizing Traditional Java Applications
Jav
^

Internal External
LAMP Stack
Java
Linux
.NET
.NET IIS
Windows
No idea what the app
is made of
Original app authors are
no longer around
When was it last
updated?
Don’t change it! Don’t
break it
Common Challenges
Of A Legacy App

Modernize Traditional Apps with Docker
Enterprise Edition to get
portability, security and efficiency of
apps without changing the code
You have to cut into the
80%
To Fuel The Innovation

Docker EE Gives Legacy Applications Modern Capabilities
without any re-coding or refactoring of the app
Efficient Portable Secure
Optimize CapEx
and OpEx costs
Infrastructure
Independent Apps
Reduce risk and
enforce new controls
Size of Infrastructure
50%
Reduction
Deployment Speed MTTR for Patching
up to
90%
Faster
up to
90%
Faster

Docker EE saves time and money
Efficient
Optimize CapEx
and OpEx costs
Reduce Total IT Costs by 50%
• Consolidate infrastructure
• Reduce software costs
• Gain operational efficiency

Eliminate the outdated app runbook for a simple
Dockerfile
Before After
● VMs contain a full OS instance within each VM
● Containers share the kernel of a single OS instance on the physical or virtual server
● Average infrastructure consolidation is 50%

Streamline configuration management
Before
100 Page Binder
● Replace the printed (often out of date) runbooks for
app deployment and ops documentation
● Dockerfile contains all commands to assemble a
Docker container
● Define instructions including: ports, volumes,
environment variables, healthchecks and more
After
Single Text File
● Dockerfile containing all the instructions to
deploy your app.
● Enables consistent deployments across
multiple environments, and eliminates the
problem of “snowflake infrastructure”

Eliminate the outdated app runbook for a simple Dockerfile
Simplify app configuration management
● define app configs in Dockerfile (single container) or Stack file
(multi-container)
Eliminate configuration drift
● No more patching in place, deploy new
● New deployment = new container image and tag in registry
● `docker diff` command shows exactly what’s changed in the container
compared to the dockerfile

Improve asset management
● Centrally manage all container
images in a private registry
● Keep a record of all versions
(tags) of images available for

Improve app operations: deployments, rollback with built in
app reliability
● Copy and paste or single command to
deploy apps and define state
● Rolling updates reduce the risk of new
deployments
● Easy roll back to previous known container
● Built in health checks continually monitor
containers
● Automatic rescheduling of containers in
the event of a failure

Docker EE ensures hybrid cloud portability
Deploy any app anywhere
• Applications can move across
multiple infrastructures
• Infrastructure agnostic propertiesPortable
Infrastructure
Independent Apps

Containers abstract applications from infrastructure
• Eliminates the “works on my machine” problem
• Containers packages code and dependencies
together into an isolated process
• Containers standardize any workload: legacy,
microservices, ISV apps (Windows and Linux)
• App configurations “travel” with the app, are not built
to the infrastructure
• Easy app composition of simple to complex apps
with security, networks, storage, env variables, ports

Container architecture provides infrastructure agnostic
packaging and tooling
Disparate IT Infrastructure
Host OS
Docker EE
Container
App A
Bins/Lib
Linux Mainframe AWS Azure
Other
Public Clouds
Windows
Container
App B
Bins/Lib
Container
App C
Bins/Lib
Container
App D
Bins/Lib
Container
App E
Bins/Lib

Get infrastructure flexibility and portability for legacy apps
Dev Test Prod
Developer can work in
whatever environment
they're used to
Application gets moved
into Test/QE
environment
Application can then be
promoted to production on any
public, private, or hybrid
infrastructure
Security
Scan
Security
Scan

Reduce risk profile
• More secure environment
• Reduce surface area
• Vulnerability management
Secure
Reduce risk and
enforce new controls
Docker EE enhances application security

Reduce the attack surface area of legacy apps
• Reduce risk associated with older code
and components
• Default out of the box settings provide
greater security
• Configurable settings allow admins to
further isolate the app
• Eliminate all unnecessary syscalls,
process, and access to host resources
pid namespace
mnt namespace
net namespace
uts namespace
user namespace
pivot_root
uid/gid drop
cap drop
all cgroups
selinux
apparmor
seccomp
1. Out of the box
default settings and
profiles
2. Granular controls
to customize settings

Run apps on the most secure environment
• The most secure container runtime and
orchestration architecture
• Secure by default with out of the box
configurations
• Cryptographic node identity
• Automatic mutual TLS across all nodes
within the Docker cluster
• Transparent and automatic cert rotation
• External CA integration
• Optionally encrypt container to container
traffic
Certificate
Authority
TLS
Certificate
Authority
TLS
Certificate
Authority
TLS
TLS TLSTLS

Make apps safer with vulnerability scanning and monitoring
• Security scanning performs binary level
scanning of application
• Detailed BOM provides security profile of
application packages
• Make informed decisions before
deployment
• BOM is maintained and continuously
monitored against leading CVE
databases

Leverage a secure and automated software supply chain
• Establish chain of trust with apps as they move across environments
• Digitally sign containers and only run verified containers
• Freshness guarantee ensures no tampering and latest container is running
• Automate workflow with immutable repos and automated image promotion

Granular access control for users, apps and nodes
• Restrict access to apps and resources
• Leverage predefined or custom roles
available to manage access and
permissions
• Create logical or physical isolation
between apps and teams

Docker 2017 - Confidential
MTA Process

Methodology: Docker EE Modernizes
Apps and Infrastructure
Existing
Application
Modern
Methodologies
Integrate to CI/CD
and automation
system
Convert to a
container
with Docker EE
Modern
Infrastructure
Built on premise, in the
cloud, or as part of a
hybrid environment.
Modern
Microservices
Add new services or
start peeling off
services from monolith
code base
App

Breaking down the deployment savings
App deployments before and after Docker
53
~100 man
hours
~<24 man
hours
Before: Traditional App Deployment : Manual, Risky, Slow
Take Offline Deploy Smoke Test Acceptance Test Go/No-Go
• Long running
processes with several
manual steps
• Scheduled out of
hours
• Disruption to users
• Lengthy Install
Guide(50 pages, 100
man hours to write)
usually word
document and mostly
inaccurate
• Bloated App binaries
• Bloated App files
• Bloated test
documents
• Requires prior
knowledge of the app
• Manual tests requires
Dev and Ops
• Manual bloated
regression pack, takes
multi hours
• Low confidence rate
• Rollback is repeat of
the entire process
After with Docker: Modern App Deployment : Automated, Proven, Fast
Take Offline Deploy Acceptance test Go/No-Go
• Need not be
scheduled out of hours
• No disruption to users
• ONE single command
• ONE light Docker
image
• Built in health checks
• Automated
Regression Pack
• Rapid addition of new
features
• High confidence rate
• Fast rollback
repeatable
After : Modern App Deployment : Automated, Proven, Fast
Before : Traditional App Deployment : Manual, Risky, Slow
Docker 2017 - CONFIDENTIAL

54
Before we start hands-on labs
https://github.com/dockersamples/javaee-demo
https://goto.docker.com/IBM-Index-PWD.html
Make sure you can get to these sites:

Hands-on exercise #2:
Migrate a JEE application Docker
1. Open https://github.com/dockersamples/javaee-demo
2. Navigate to movieplex7
and open “Dockerfile”
• Multi-stage
• Stage 1 builds .war
• Stage 2 builds
deployable image

Hands-on exercise #2 (cont’):
Migrate a JEE application to Docker
3. Open https://goto.docker.com/IBM-Index-PWD.html
(if PWD session is not already open)
4. Click the “DTR” link and login if prompted
User: admin - Password: admin1234
5. Click “System” on left and turn on the “Create Repository on Push”
toggle near bottom of page.

Migrate a JEE application to Docker
6. Return to Play-With-Docker page, open the “manager1”
terminal and run:
git clone https://github.com/dockersamples/javaee-demo.git
7. cd javaee-demo/movieplex7
8. docker login [your DTR hostname]
9. docker build -t [your DTR hostname]/admin/movieplex7:1 .
10. docker push [your DTR hostname]/admin/movieplex7:1

Deploying to Clusters
Services, Stacks and Swarms

More terminology
Current Clustering
● Swarm
○ A group of docker hosts, connected and running as
a cluster
○ 1-n managers
○ 1-n workers
● Service
○ An application (or part of an application) that
provides a specific function (catalog lookup, web
front end, payment processing)
● Stack
○ A way of representing multi-service applications
○ Made up of 1-n services

Hands-on exercise #2.5:
Deploy to cluster
1. In GitHub page, navigate to movieplex7 subdirectory and
open “docker-stack.yml”, copy contents of file.
2. Open UCP dashboard (link on Play With Docker page)
3. In UCP under “Shared Resources”, Click “Stacks” and then click
“Create Stack” in top right.
4. Enter any name, chose “Swarm Services” in “Mode” dropdown and
paste above yml into the “Compose.Yml” editor field.
5. Change the “image:” value to:
[Your DTR host]/admin/movieplex7:1
6. Change the “ports:” value to: “-18080:8080”

Hands-on exercise #2.5 (cont’):

Deploy to cluster
7. Click “Create” in bottom-right
8. Output in next page should look similar to
this:
9. Click “Done” to return to the
UCP Dashboard:

10. You should now see your stack in the table
11. Click on it, and then “Services” from the
“Inspect Resource” dropdown on the right:
Deploy to cluster

12. Your service should be in the list:
13. Click on it, and then the URL under
“Published Endpoints” on the right:
Deploy to cluster

14. The Apache Tomcat manager should come up
15. Add “movieplex7” to the url and you should see the
application front page.
Congratulations!
You have containerized
a JEE webapp!
Deploy to cluster

Hands-on exercise #3:
Adding services
1. Return to GitHub,navigate to the react-client directory
and open “Dockerfile”
• Also multi-stage
• Stage 1 builds NodeJS
application
• Stage 2 builds
deployable image

Adding services
2. Return to Play-With-Docker page, open the “manager1”
terminal and get back into the top directory of your git
checkout (javaee-demo directory)
3. Run “./add_ee_pwd_host.sh” to add an ENV line to the
react-client/Dockerfile (feel free to look at it)
4. cd react-client
5. docker build -t [your DTR hostname]/admin/react-client:1 .
6. docker push [your DTR hostname]/admin/react-client:1

7. In GitHub page, navigate to top directory and
open “docker-stack.yml”, copy contents of file.
8. Open UCP dashboard (link on Play With Docker page)
9. In UCP under “Shared Resources”, Click “Stacks” and then click
“Create Stack” in top right.
10. Enter any name, chose “Swarm Services” in “Mode” dropdown and
paste above yml into the “Compose.Yml” editor field.
11. Change the “image:” values respectively:
• [Your DTR host]/admin/movieplex7:1
• [Your DTR host]/admin/react-client:1
Adding services

Adding Services
12. Click “Create” in bottom-right
13. Output in next page should look similar to
this:
14. Click “Done” to return to the
UCP Dashboard:

15. You should now see your stack in the table
16. Click on it, and then “Services” from the
“Inspect Resource” dropdown on the right:
Adding Services

17. There should be a service with a name ending in
“_react-client”
18. Click on it, and then the URL under
“Published Endpoints” on the right:
Deploy to cluster

19. You should see the new UI for the application.
Congratulations!
You have added a new
front-end to the JEE
webapp!
Deploy to cluster

Section 3:
Going to production

Health Checks
Helping Docker help you
● HEALTHCHECK instruction in DockerFile
● Tells Docker how to test a container to check that it is still
working
● New status added to container lists
● Adds “(healthy)” to Status column in a “docker ps
response”

Health Checks
Helping Docker help you
● Examples:
○ HEALTHCHECK CMD curl --fail http://localhost || exit 1
○ HEALTHCHECK --interval=12s --timeout=12s --start-period=30s
CMD node /healthcheck.js
● References:
○ Documentation: https://docs.docker.com/engine/reference/builder/#healthcheck
○ Elton Stoneman blog about not using curl/iwr: https://t.co/Zgdd1lyzhk

JVM Memory
Tips and tricks
● Always explicitly specify JVM heap size with “-Xmx”
arguments
○ By default, J2SE 5.0+ will use up to 25% of the
host machine’s RAM or 1GB (whichever is smaller)
○ Container memory limits (enforced via cgroups) are
ignored pre-Java 9*
○ It’s just a good practice to specify it anyway
● Do use Docker cpu and memory reservations and limits
to avoid over-subscribing your host machines
○ --memory
○ --memory-reservation
○ --cpus
○ etc…
● If limiting cpu, be sure to update GC Thread limiter in
JVM
○ -XX:ParallelGCThreads

Logging
Dealing with application logs
● Docker EE Reference Architecture document about this:
http://dockr.ly/logging
● Do not output logs into the container’s RW layer
○ slow
○ have to exec or cp out of the container to see them
● Option 1: send logs to stdout (see logging drivers below)
○ Visible via “docker logs” command
○ Visible via Docker UCP web console
● Option 2: send logs to volume
○ Many use a centralized NAS/SAN volume for this
● Option 3: Docker logging drivers

Docker Log Drivers
Log drivers available (as of 2/16/18)
Latest always available at:
https://docs.docker.com/engine/admin/logging/overview/#supported-logging-drivers

Application Log Drivers
Consider the following when selecting application log drivers:
● syslog and splunk:
○ Good options if log data is highly sensitive since
they can be configured to use TLS for transporting
logs.
● journald:
○ great for retaining the usage of docker logs as well
as logging Docker daemon logs
○ allows for easier troubleshooting and log portability
at the same time
○ logs write first locally, so that there is less reliance
on logging infrastructure.
● awslogs or gcplogs:
○ Only if cluster exist solely on a single cloud provider

Application Log Drivers
(continued)
Consider the following when selecting application log drivers:
● gelf and fluentd:
○ good choice if there's a NoSQL database somewhere in the environment where the
logs can be stored.
Again, see http://dockr.ly/logging for much more detail on logging.

Troubleshooting
How to use Java tools with container based JVMs
● JVM command line tools via docker exec
○ GC Stats: jstat --gcutil
○ Heap dumps/histograms: jmap
● Expose JMX ports for jconsole or other utilities
● Intelligent health checks
○ More than just “port 8080 is listening”
● Check third party monitoring tools for updated to be “container aware”
○ i.e. Licensing issues with older monitoring tools because each container appears
as a new host
● Also, docker specific commands/tools:
○ docker stats
○ ctop

Application Configuration
Managing multi-environment config’s

Application Configuration
Deploying to disparate environments with identical images
● Build artifacts are your Docker images, not .war files or similar
● Build images in CI, store in registry, deploy same images everywhere
● Patterns and tools to deal with configuration differences
○ Separate Stack yaml files
○ Docker secrets
○ Application configuration via volume mounts
○ Third party configuration tools such as Consul and/or Vault
■ consul-template
■ Joyent Containerpilot
■ Roll-your-own

Environment specific Stacks
● Different environment variable values
● Services that mock production endpoints
○ db
○ web service
prod.yml
dev.yml

Docker Secrets
● Stored encrypted in swam
● Exposed only to nodes that run services that need them
● Presented in container via RAM only tmpfs files
○ never persisted to disk in encrypted format
○ when container stops, secret is no longer present
● All communications between swam nodes via TLS, so
secret never in the clear on the wire either
● Different secret values per environment using tags
● UCP can manage who/where secrets are available

Application configuration in
volume mounts
● Use volumes that are only available in physical environment they apply to
● Contain environment-specific application configuration properties
● DO NOT store secrets in these (use Docker Secrets or other secure mechanism)
● You can bind mount files (doesn’t have to be full directory structures)

CI / CD With Docker EE
● Docker Reference Architecture: Development Pipeline Best Practices Using Docker EE
○ http://bit.ly/2sbnSHL

CI / CD With Docker EE
● Integrating CI/CD with Docker EE Webinar with GitLab demo:
○ http://dockr.ly/2GTvC54

Resources
So much to talk about, so little time to do so!
● Docker Resources: https://www.docker.com/products/resources
○ Development Pipeline Best Practices Using Docker EE: http://bit.ly/2sbnSHL
○ Logging Reference Architecture: http://dockr.ly/logging
○ Integrating CI/CD with Docker EE Webinar: http://dockr.ly/2GTvC54
○ Training: https://training.docker.com
■ Instructor led
■ Self paced with “Play With Docker”
○ Want Docker to help you with an MTA effort?
■ https://docker.com/MTA
● SquareSpace Blog: Understanding Linux Container Scheduling (with JVMs)
https://engineering.squarespace.com/blog/2017/understanding-linux-container-scheduling

Docker Enterprise Edition
Docker Community Edition
containerd
1
2
3
4
The best container
development workflow
The best enterprise
container security and
management
Native Kubernetes
integration provides full
ecosystem
compatibility Industry-standard
container runtime
Docker with Swarm and Kubernetes

Discover. Collaborate. Deploy.
Using Docker to build, ship and run
Kubernetes applications
Patrick Chanezon
Chief Developer Advocate at Docker, Inc.
11:30 AM-12:15 PM | Thursday, Feb. 22
Moscone West/Level 2, Room 2005
Session type: Breakout Session
Track: Cloud, Containers & Infrastructure
Docker Desktop and Enterprise Edition now both include
Kubernetes as an optional orchestration component. This
talk will explain how to use Docker Desktop (Mac or
Windows) to develop and debug a cloud native application,
then how Docker Enterprise Edition helps you deploy it to
Kubernetes in production.
https://developer.ibm.com/indexconf/sessions/#!?id=5461

DockerCon San Francisco
June 12-15
www.dockercon.com
Use code ‘Index2018’ for 10% off

IBM Index 2018 Conference Workshop: Modernizing Traditional Java App's with Docker

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a IBM Index 2018 Conference Workshop: Modernizing Traditional Java App's with Docker

Semelhante a IBM Index 2018 Conference Workshop: Modernizing Traditional Java App's with Docker (20)

Mais de Eric Smalling

Mais de Eric Smalling (18)

Último

Último (20)

IBM Index 2018 Conference Workshop: Modernizing Traditional Java App's with Docker