IBM Index 2018 Conference Workshop: Modernizing Traditional Java App's with Docker
22 de Feb de 2018•0 gostou
2 gostaram
Seja o primeiro a gostar disto
mostrar mais
•2,087 visualizações
visualizações
Vistos totais
0
No Slideshare
0
De incorporações
0
Número de incorporações
0
Baixar para ler offline
Denunciar
Software
Slides from my 2.5 hour hands-on workshop covering Docker basics, the Docker MTA program and how it applies to legacy Java applications and some tips on running those apps in containers in production.
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
• 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?
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”
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
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
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.
Hands-on exercise #2 (cont’):
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
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:
Hands-on exercise #2.5 (cont’):
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:
Hands-on exercise #2.5 (cont’):
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!
Hands-on exercise #2.5 (cont’):
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
Hands-on exercise #3 (cont’):
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
Hands-on exercise #3 (cont’):
Adding services
Hands-on exercise #3 (cont’):
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:
Hands-on exercise #3 (cont’):
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:
Hands-on exercise #3 (cont’):
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!
Hands-on exercise #3 (cont’):
Deploy to cluster
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
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