Multi-Stage Builds

This is part of a series of articles describing how the AtSea Shop application was built using enterprise development tools and Docker. In the previous post, I introduced the AtSea application and how I developed a REST application with the Eclipse IDE and Docker. Multi-stage builds, a Docker feature introduced in Docker 17.06 CE, let you orchestrate a complex build in a single Dockerfile. Before multi-stage build, Docker users would use a script to compile the applications on the host machine, then use Dockerfiles to build the images. The AtSea application is the perfect use case for a multi-stage build because:

it uses node.js to compile the ReactJs app into storefront
it uses Spring Boot and Maven to make a standalone jar file
it is deployed to a standalone JDK container
the storefront is then included in the jar

Let’s look at the Dockerfile.
The react-app is an extension of create-react-app. From within the react-app directory we run AtSea’s frontend in local development mode.
The first stage of the build uses a Node base image to create a production-ready frontend build directory consisting of static javascript and css files. A Docker best practice is named stages, e.g. “FROM node:latest AS storefront”.
This step first makes our image’s working directory at /usr/src/atsea/app/react-app. We copy the contents of the react-app directory, which includes the ReactJs source and package.json file, to the root of our image’s working directory. Then we use npm to install all necessary react-app’s node dependencies. Finally, npm run build bundles the react-app using the node dependencies and ReactJs source into a build directory at the root.
FROM node:latest AS storefront
WORKDIR /usr/src/atsea/app/react-app
COPY react-app .
RUN npm install
RUN npm run build
Once this build stage is complete, the builder has an intermediate image named storefront. This temporary image will not show up in your list of images from a docker image ls. Yet the builder can access and choose artifacts from this stage in other stages of the build.
To compile the AtSea REST application, we use a maven image and copy the pom.xml file, which maven uses to install the dependencies. We copy the source files to the image and run maven again to build the AtSea jar file using the package command. This creates another intermediate image called appserver.
FROM maven:latest AS appserver
WORKDIR /usr/src/atsea
COPY pom.xml .
RUN mvn -B -f pom.xml -s /usr/share/maven/ref/settings-docker.xml dependency:resolve
COPY . .
RUN mvn -B -s /usr/share/maven/ref/settings-docker.xml package -DskipTests
Putting it all together, we use a java image to build the final Docker image. The build directory in storefront, created during the first build stage, is copied to the /static directory, defined as an external directory in the AtSea REST application. We are choosing to leave behind all those node modules :).
We copy the AtSea jar file to the java image and set ENTRYPOINT to start the application and set the profile to use a PostgreSQL database. The final image is compact since it only contains the compiled applications in the JDK base image.
FROM java:8-jdk-alpine
WORKDIR /static
COPY –from=storefront /usr/src/atsea/app/react-app/build/ .
WORKDIR /app
COPY –from=appserver /usr/src/atsea/target/AtSea-0.0.1-SNAPSHOT.jar .
ENTRYPOINT [“java”, “-jar”, “/app/AtSea-0.0.1-SNAPSHOT.jar”]
CMD [“–spring.profiles.active=postgres”]
This step uses COPY –from command to copy files from the intermediate images. Multi-stage builds can also use offsets instead of named stages, e.g.  “COPY –from=0 /usr/src/atsea/app/react-app/build/ .”
Multi-stage builds facilitate the creation of small and significantly more efficient containers since the final image can be free of any build tools. External scripts are no longer needed to orchestrate a build. Instead, an application image is built and started by using docker-compose up –build. A stack is deployed using docker stack deploy -c docker-stack.yml.
Multi-Stage Builds in Docker Cloud
Docker Cloud now supports multi-stage builds for automated builds. Linking the github repository to Docker Cloud ensures that your images will be always be current. To enable automated builds, tag and push your image to your Docker Cloud repository.
docker tag atsea_app <your username>/atsea_app
docker push <your username>/atsea_app
Log into your Docker Cloud account.

Next connect your Github account to give Cloud access to the source code. Click on Cloud Settings, then click on sources, and the plug icon. Follow the directions to connect your Github account.

After your Github account is connected, click on Repositories on the side menu and then click your atsea_app repository.

Click on Builds, then click on Configure Automated Builds on the following screen.

In the Build Configurations form, complete

the Source Repository with the Github account and repository
the Build Location, we’ll use Docker Cloud with a medium node
the Docker Version using Edge 17.05 CE which supports multi-stage builds
leave Autotest to off
create a Build Rule that specifies the dockerfile in the app directory of the repository

Click on Save and Build to build the image.

Docker Cloud will notify you if the build was successful.

For more information on multi-stage builds read the documentation and Docker Captain Alexis Ellis’ Builder pattern vs. Multi-stage builds in Docker. To build compact and efficient images watch Abby Fuller’s Dockercon 2017 presentation, Creating Effective Images and check out her slides.
Interested in more? Check out these developer resources and videos from Dockercon 2017.

AtSea Shop demo
Docker Reference Architecture: Development Pipeline Best Practices Using Docker EE
Automated Builds in Docker Cloud
Docker Labs

Developer Tools
Java development using docker

DockerCon videos

Docker for Java Developers
The Rise of Cloud Development with Docker & Eclipse Che
All the New Goodness of Docker Compose
Docker for Devs

Multi-stage builds in the #DockerCon AtSea demo app by @spara @jessvalarezo1Click To Tweet

The post Multi-Stage Builds appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Kubernetes 1.7: Security Hardening, Stateful Application Updates and Extensibility

Today we’re announcing Kubernetes 1.7, a milestone release that adds security, storage and extensibility features motivated by widespread production use of Kubernetes in the most demanding enterprise environments. At-a-glance, security enhancements in this release include encrypted secrets, network policy for pod-to-pod communication, node authorizer to limit kubelet access and client / server TLS certificate rotation. For those of you running scale-out databases on Kubernetes, this release has a major feature that adds automated updates to StatefulSets and enhances updates for DaemonSets. We are also announcing alpha support for local storage and a burst mode for scaling StatefulSets faster. Also, for power users, API aggregation in this release allows user-provided apiservers to be served along with the rest of the Kubernetes API at runtime. Additional highlights include support for extensible admission controllers, pluggable cloud providers, and container runtime interface (CRI) enhancements.What’s NewSecurity:The Network Policy API is promoted to stable. Network policy, implemented through a network plug-in, allows users to set and enforce rules governing which pods can communicate with each other. Node authorizer and admission control plugin are new additions that restrict kubelet’s access to secrets, pods and other objects based on its node.Encryption for Secrets, and other resources in etcd, is now available as alpha. Kubelet TLS bootstrapping now supports client and server certificate rotation.Audit logs stored by the API server are now more customizable and extensible with support for event filtering and webhooks. They also provide richer data for system audit.Stateful workloads:StatefulSet Updates is a new beta feature in 1.7, allowing automated updates of stateful applications such as Kafka, Zookeeper and etcd, using a range of update strategies including rolling updates.StatefulSets also now support faster scaling and startup for applications that do not require ordering through Pod Management Policy. This can be a major performance improvement. Local Storage (alpha) was one of most frequently requested features for stateful applications. Users can now access local storage volumes through the standard PVC/PV interface and via StorageClasses in StatefulSets.DaemonSets, which create one pod per node already have an update feature, and in 1.7 have added smart rollback and history capability.A new StorageOS Volume plugin provides highly-available cluster-wide persistent volumes from local or attached node storage.Extensibility:API aggregation at runtime is the most powerful extensibility features in this release, allowing power users to add Kubernetes-style pre-built, 3rd party or user-created APIs to their cluster.Container Runtime Interface (CRI) has been enhanced with New RPC calls to retrieve container metrics from the runtime. Validation tests for the CRI have been published and Alpha integration with containerd 1.0, which supports basic pod lifecycle and image management is now available. Read our previous in-depth post introducing CRI.Additional Features:Alpha support for external admission controllers is introduced, providing two options for adding custom business logic to the API server for modifying objects as they are created and validating policy. Policy-based Federated Resource Placement is introduced as Alpha providing placement policies for the federated clusters, based on custom requirements such as regulation, pricing or performance.Deprecation: Third Party Resource (TPR) has been replaced with Custom Resource Definitions (CRD) which provides a cleaner API, and resolves issues and corner cases that were raised during the beta period of TPR. If you use the TPR beta feature, you are encouraged to migrate, as it is slated for removal by the community in Kubernetes 1.9.The above are a subset of the feature highlights in Kubernetes 1.7. For a complete list please visit the release notes.AdoptionThis release is possible thanks to our vast and open community. Together, we’ve already pushed more than 50,000 commits in just three years, and that’s only in the main Kubernetes repo. Additional extensions to Kubernetes are contributed in associated repos bringing overall stability to the project. This velocity makes Kubernetes one of the fastest growing open source projects — ever. Kubernetes adoption has been coming from every sector across the world. Recent user stories from the community include: GolfNow, a member of the NBC Sports Group, migrated their application to Kubernetes giving them better resource utilization and slashing their infrastructure costs in half.Bitmovin, provider of video infrastructure solutions, showed us how they’re using Kubernetes to do multi-stage canary deployments in the cloud and on-prem.Ocado, world’s largest online supermarket, uses Kubernetes to create a distributed data center for their smart warehouses. Read about their full setup here.Is Kubernetes helping your team? Share your story with the community. See our growing resource of user case studies and learn from great companies like Box that have adopted Kubernetes in their organization. Huge kudos and thanks go out to the Kubernetes 1.7 release team, led by Dawn Chen of Google. AvailabilityKubernetes 1.7 is available for download on GitHub. To get started with Kubernetes, try one of the these interactive tutorials. Get InvolvedJoin the community at CloudNativeCon + KubeCon in Austin Dec. 6-8 for the largest Kubernetes gathering ever. Speaking submissions are open till August 21 and discounted registration ends October 6.The simplest way to get involved is joining one of the many Special Interest Groups (SIGs) that align with your interests. Have something you’d like to broadcast to the Kubernetes community? Share your voice at our weekly community meeting, and these channels:Post questions (or answer questions) on Stack OverflowJoin the community portal for advocates on K8sPortFollow us on Twitter @Kubernetesio for latest updatesConnect with the community on SlackShare your Kubernetes story. Many thanks to our vast community of contributors and supporters in making this and all releases possible.– Aparna Sinha, Group Product Manager, Kubernetes Google and Ihor Dvoretskyi, Program Manager, Kubernetes Mirantis
Quelle: kubernetes

Announcing Docker 17.06 Community Edition (CE)

Today we released Docker CE 17.06  with new features, improvements, and bug fixes. Docker CE 17.06 is the first Docker version built entirely on the Moby Project, which  we announced in April at DockerCon. You can see the complete list of changes in the changelog, but let’s take a look at some of the new features.
We also created a video version of this post here:

Multi-stage builds
The biggest feature in 17.06 CE is that multi-stage builds, announced in April at DockerCon, have come to the stable release. Multi-stage builds allow you to build cleaner, smaller Docker images using a single Dockerfile.
Multi-stage builds work by building intermediate images that produce an output. That way you can compile code in an intermediate image and use only the output in the final image. So for instance, Java developers commonly use Apache Maven to compile their apps, but Maven isn’t required to run their app. Multi-stage builds can result in a substantial image size savings:
REPOSITORY          TAG                 IMAGE ID                CREATED              SIZE

maven               latest              66091267e43d         2 weeks ago         620MB

java                8-jdk-alpine     3fd9dd82815c         3 months ago       145MB
Let’s take a look at our AtSea sample app which creates a sample storefront application.

AtSea uses multi-stage build with two intermediate stages: a node.js base image to build a ReactJS app, and a Maven base image to compile a Spring Boot app into a single image.
.gist table { margin-bottom: 0; }

The final image is only 209MB, and doesn’t have Maven or node.js.
There are other builder improvements as well, including the –build-arg flag on docker build, which lets you set build-time variables. The ARG instruction lets Dockerfile authors define values that users can set at build-time using the –build-arg flag.
Logs and Metrics
 
Metrics
We currently support metrics through an API endpoint in the daemon. You can now expose docker’s /metrics endpoint to plugins.

$ docker plugin install –grant-all-permissions cpuguy83/docker-metrics-plugin-test:latest

$ curl http://127.0.0.1:19393/metrics

This plugin is for example only. It runs reverse proxy on the host’s network which forwards requests to the local metrics socket in the plugin. In real scenarios you would likely either push the collected metrics to an external service or make the metrics available for collection by a service such as Prometheus.
Note that while metrics plugins are available on non-experimental daemons, the metric labels are still considered experimental and may change in future versions of Docker.
 
Log Driver Plugins
We have added support for log driver plugins.
 
Service logs
Docker service logs has moved out of the Edge release and into Stable, so you can easily get consolidated logs for an entire service running on a Swarm. We’ve added an endpoint for logs from individual tasks within a service as well.

Networking
 
Node-local network support for Services
Docker supports a variety of networking options. With Docker 17.06 CE, you can now attach services to node-local networks. This includes networks like Host, Macvlan, IPVlan, Bridge, and local-scope plugins. So for instance for a Macvlan network you can create a node specific network configurations on the worker nodes and then create a network on a manager node that brings in those configurations:
[Wrk-node1]$ docker network create —config-only —subnet=10.1.0.0/16 local-config

[Wrk-node2]$ docker network create —config-only —subnet=10.2.0.0/16 local-config

[Mgr-node2]$ docker network create —scope=swarm —config-from=local-config -d macvlan

mynet

[Mgr-node2]$ docker service create —network=mynet my_new_service

Swarm mode
We have a number of new features in swarm mode. Here’s just a few of them:

Configuration Objects
We’ve created a new configuration object for swarm mode that allows you to securely pass along configuration information in the same way you pass along secrets.
$ echo “This is a config” | docker config create test_config –

$ docker service create –name=my-srv —config=test_config …

$ docker exec -it 37d7cfdff6d5 cat test_config

This is a config

Certificate Rotation Improvements
The swarm mode public key infrastructure (PKI) system built into Docker makes it simple to securely deploy a container orchestration system. The nodes in a swarm use mutual Transport Layer Security (TLS) to authenticate, authorize, and encrypt the communications between themselves and other nodes in the swarm. Since this relies on certificates, it’s important to rotate those frequently. Since swarm mode launched with Docker 1.12, you’ve been able to schedule certificate rotation as frequently as every hour. With Docker CE 17.06 we’ve added the ability to immediately force certificate rotation on a one-time basis.
docker swarm ca –rotate
Swarm Mode Events
You can use docker events to get real-time event information from Docker. This is really useful when writing automation and monitoring applications that work with Docker. But until Docker CE 17.06 CE we didn’t have support for events for swarm mode. Now you docker events will return information on services, nodes, networks, and secrets.

Dedicated Datapath
The new –datapath-addr flag on docker swarm init allows you to isolate the swarm mode management tasks from the data passed around by the application. That helps save the cluster from IO greedy applications. For instance in you initiate your cluster:
docker swarm init —advertise-addr=eth0 —datapath-addr=eth1
Cluster management traffic (Raft, grpc & gossip) will travel over eth0 and services will communicate with each other over eth1.

Desktop Editions
We’ve got three new features in Docker for Mac and Windows.

GUI option to reset docker data without loosing all settings
Now you can reset your data without resetting your settings

Add an experimental DNS name for the host
If you’re running containers on Docker for Mac or Docker for Windows, and you want to access other containers you can use a new experimental host: docker.for.mac.localhost and docker.for.win.localhost to access open ports. For instance:
.gist table { margin-bottom: 0; }

Login certificates for authenticating registry access
You can now add certificates to Docker for Mac and Docker for Windows that allow you to access registries, not just your username and password. This will make accessing Docker Trusted Registry, as well as the open source Registry and any other registry application fast and easy.

Cloud Editions
 
Our Cloudstor volume plugin is available both on Docker for AWS and Docker for Azure. In Docker for AWS, support for persistent volumes (both global EFS-based and attachable EBS-based) are now available in stable. And we support EBS volumes across Availability Zones.
For Docker for Azure, we now support deploying to Azure Gov. Support for persistent volumes through cloudstor backed by Azure File Storage is now available in Stable for both Azure Public and Azure Gov
 
Deprecated
 
In the dockerd commandline, we long ago deprecated the –api-enable-cors flag in favor of –api-cors-header. We’re not removing –api-enable-cors entirely.
Ubuntu 12.04 “precise pangolin” has been end-of-lifed, so it is now no longer a supported OS for Docker. Later versions of Ubuntu are still supported.
 
What’s next
 
To find out more about these features and more:

Download the latest version of Docker CE
Check out the Docker Documentation
Play with these features on Play with Docker
Ask questions in our forums and in the Docker Community Slack
RSVP for the CE 17.06 Online Meetup on June 28th

The post Announcing Docker 17.06 Community Edition (CE) appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Docker at Nutanix .NEXT Conference – Visit us at Booth #S11

Today marks the start of Nutanix .NEXT Conference in Washington, D.C., the annual conference for Nutanix customers and partners. One of the major themes of the conference is hybrid cloud, and Docker will be there to demonstrate how Docker Enterprise Edition delivers application portability across different infrastructure platforms through a complete enterprise-ready Container as a Service (CaaS) solution for IT.
Docker and Nutanix will also be highlighting the Nutanix Docker Volume Plug-in (DVP), a Docker Certified Plugin available in the Docker Store. This plugin connects Docker containers to enterprise-grade persistent storage from Nutanix even as the container is powered on, powered off, or moved to a new host. As part of the certification process, Docker and Nutanix validate that the plugin is built with Docker recommended best practices and passes an additional suite of API compliance testing and vulnerability scanning. Docker EE customers also have access to support from both Docker and Nutanix.

 
Watch a Demo of Docker EE at Nutanix .NEXT
For those heading to Nutanix .NEXT, be sure to swing by booth #S11 to learn more about this plugin as well as other IT use cases for EE. Watch a demo and grab some Docker swag while you learn how IT organizations can modernize their data centers, save on costs, and improve security with Docker Enterprise Edition.
Also make sure to join us for these sessions and add them to your agenda:
Building a Secure Software Supply Chain with Docker Enterprise Edition
Speaker: Banjot Chanana, Senior Director Product Management, Docker
Date: Wednesday, June 28th
Time: 3:00pm – 3:20pm
Place: Solution Expo Theater
The Wonderful World of Containers and Nutanix
Speakers: Banjot Chanana, Senior Director Product Management at Docker and Binny Gill, Chief Architect at Nutanix
Date: Thursday, June 29th
Time: 3:05pm – 3:55pm
Place: Maryland A
The Wonderful World of Containers and Nutanix (repeat)
Speakers: Banjot Chanana, Senior Director Product Management at Docker and Binny Gill, Chief Architect at Nutanix
Date: Friday, June 30th
Time: 9:00am – 9:50am
Place: Woodrow Wilson BCD
The road to hybrid cloud starts with application portability. Docker Enterprise Edition uniquely provides flexibility and choice for businesses to adopt a single, multi or hybrid cloud environment without conflict.

Check out #Docker Enterprise at Nutanix .NEXT in DC at Booth S11 Click To Tweet

More resources to get you started:

Learn more about Docker Enterprise Edition
Try Docker Enterprise Edition for free
Download the Nutanix Docker Volume Plug-in from Docker Store

The post Docker at Nutanix .NEXT Conference – Visit us at Booth #S11 appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Kubespray Ansible Playbooks foster Collaborative Kubernetes Ops

Today’s guest post is by Rob Hirschfeld, co-founder of open infrastructure automation project, Digital Rebar and co-chair of the SIG Cluster Ops.  Why Kubespray?Making Kubernetes operationally strong is a widely held priority and I track many deployment efforts around the project. The incubated Kubespray project is of particular interest for me because it uses the popular Ansible toolset to build robust, upgradable clusters on both cloud and physical targets. I believe using tools familiar to operators grows our community.We’re excited to see the breadth of platforms enabled by Kubespray and how well it handles a wide range of options like integrating Ceph for StatefulSet persistence and Helm for easier application uploads. Those additions have allowed us to fully integrate the OpenStack Helm charts (demo video).By working with the upstream source instead of creating different install scripts, we get the benefits of a larger community. This requires some extra development effort; however, we believe helping share operational practices makes the whole community stronger. That was also the motivation behind the SIG-Cluster Ops.With Kubespray delivering robust installs, we can focus on broader operational concerns.For example, we can now drive parallel deployments, so it’s possible to fully exercise the options enabled by Kubespray simultaneously for development and testing.  That’s helpful to built-test-destroy coordinated Kubernetes installs on CentOS, Red Hat and Ubuntu as part of an automation pipeline. We can also set up a full classroom environment from a single command using Digital Rebar’s providers, tenants and cluster definition JSON.Let’s explore the classroom example:First, we define a student cluster in JSON like the snippet below{  “attribs”: {    “k8s-version”: “v1.6.0″,    “k8s-kube_network_plugin”: “calico”,    “k8s-docker_version”: “1.12”  },  “name”: “cluster01″,  “tenant”: “cluster01″,  “public_keys”: {    “cluster01″: “ssh-rsa AAAAB….. user@example.com”  },  “provider”: {    “name”: “google-provider”  },  “nodes”: [    {      “roles”: [ “etcd”,”k8s-addons”, “k8s-master” ],      “count”: 1    },    {      “roles”: [ “k8s-worker” ],      “count”: 3    }  ]}Then we run the Digital Rebar workloads Multideploy.sh reference script which inspects the deployment files to pull out key information.  Basically, it automates the following steps:rebar provider create {“name”:“google-provider”, [secret stuff]}rebar tenants create {“name”:“cluster01”}rebar deployments create [contents from cluster01 file]The deployments create command will automatically request nodes from the provider. Since we’re using tenants and SSH key additions, each student only gets access to their own cluster. When we’re done, adding the –destroy flag will reverse the process for the nodes and deployments but leave the providers and tenants.We are invested in operational scripts like this example using Kubespray and Digital Rebar because if we cannot manage variation in a consistent way then we’re doomed to operational fragmentation.  I am excited to see and be part of the community progress towards enterprise-ready Kubernetes operations on both cloud and on-premises. That means I am seeing reasonable patterns emerge with sharable/reusable automation. I strongly recommend watching (or better, collaborating in) these efforts if you are deploying Kubernetes even at experimental scale. Being part of the community requires more upfront effort but returns dividends as you get the benefits of shared experience and improvement.When deploying at scale, how do you set up a system to be both repeatable and multi-platform without compromising scale or security?With Kubespray and Digital Rebar as a repeatable base, extensions get much faster and easier. Even better, using upstream directly allows improvements to be quickly cycled back into upstream. That means we’re closer to building a community focused on the operational side of Kubernetes with an SRE mindset.If this is interesting, please engage with us in the Cluster Ops SIG, Kubespray or Digital Rebar communities. — Rob Hirschfeld, co-founder of RackN and co-chair of the Cluster Ops SIGGet involved with the Kubernetes project on GitHub Post questions (or answer questions) on Stack Overflow Connect with the community on SlackFollow us on Twitter @Kubernetesio for latest updates
Quelle: kubernetes

Moby Summit June 2017 Recap

On June 19 2017, 90 members of the Moby community gathered at Docker headquarter in San Francisco for the second Moby Summit.  This was an opportunity for the community to discuss the progress and future of the Moby project, two months after it was announced.
We started the day with an introduction by Solomon Hykes, and a look at the website redesign: the [Moby project website](http://mobyproject.org/) now has a [blog](http://mobyproject.org/blog/), an event calendar, a list of projects, and a [community page](http://mobyproject.org/community/) with links to various community resources. The [website code is open source](https://github.com/moby/mobywebsite), issues and PRs to make it better are welcome.
Then each team gave an update on their progress: Linuxkit, containerd, InfraKit, SwarmKit and LibNetwork, as well as the three new [Moby Special Interest Groups](http://mobyproject.org/projects/), Linuxkit Security, Security Scanning & Notary and Orchestration Security. All these talks have been recorded and you can find the videos and slides below.
In the afternoon, we split into 5 Birds Of Feathers (BOF) sessions: runc/containerd, LinuxKit, InfraKit, Security, and Security Scanning. You can find links to the BOF Notes at the end of this post.
We ended the day with a recap of the BOF sessions, and some beer.
Moby Summit Introduction

LinuxKit Update
Slides: LinuxKit update

containerd Update

InfraKit Update

Slides: Infrakit update
Libnetwork update
Slides: Libnetwork update

SwarmKit update
Swarm Proxy is a program for managing Docker Swarm services behind a reverse proxy. It uses the Docker events stream to monitor for services being created and removed, and then uses Swarm Configs to update a reverse proxy service to correctly route traffic to those services. It is stateless. https://github.com/dperny/swarm-proxy

 
Security Update

Finally, the Docker security team gave the update on the following topics:

LinuxKit security update
Security scanning and Notary update
Orchestration security update

Slides: LinuxKit Security and container container scanning with Notary
Slides: Orchestration security
BOF Summary Notes
runC / containerd

https://github.com/containerd/containerd/blob/master/reports/2017-06-23.md

LinuxKit

https://github.com/linuxkit/linuxkit/blob/master/reports/2017-06-19-summit.md 

Security Scanning & Notary

https://forums.mobyproject.org/t/2017-06-19-meeing-notes/79

Orchestration Security

https://forums.mobyproject.org/t/2017-06-19-orchestration-security-sig-meeting/90

 

Check out the videos & slides from the last @moby Summit #containerd #linuxkit #infrakit Click To Tweet

The post Moby Summit June 2017 Recap appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Your Docker Agenda for Cisco Live 2017 – Booth #2900B

The Docker team is headed to Las Vegas next week for Cisco Live – visit our booth #2900B to learn more about Docker Enterprise Edition and our integration with Cisco UCS, Contiv and the Cisco Validated Designs available for modern container deployments at enterprise scale. Docker and Cisco formed a partnership earlier this year to bring validated and supported solutions for the enterprise.

Whether you are containerizing legacy apps to accelerate datacenter refresh or planning your first microservices application, Docker and Cisco deliver integrated solutions that have been tested to perform at scale – up to thousands of containers.
Add these Docker sessions to your schedule:
Tuesday, Jun 27, 1:20 pm – 1:30pm | Cloud Education Zone 
Title: Maximize ROI by Modernizing Traditional Apps with Docker and Cisco 
Tuesday, Jun 27, 3:30 pm – 4:30 pm | Level 3, South Seas A
Title: Containers and Microservices to Accelerate your Digital Business
Session ID: PSOCLD-1225
Learn how the Cisco Datacenter and Cloud portfolio and Docker Enterprise Edition are modernizing traditional apps and delivering new microservices to enable digital transformation in the enterprise.
Thursday, Jun 29, 12:40 pm – 12:50 pm | Datacenter & Cloud Education Zone
Title: Docker Enterprise Edition on Cisco UCS
Thursday, Jun 29, 1:00 pm – 2:30 pm | Level 2, Lagoon
Title: Container Networking Deep Dive with Docker EE and Cisco Contiv
Session ID: BRKSDN-2256
Get a technical deep dive into container networking architecture with Docker networking drivers, advanced use cases and best practices with Contiv. Gain practical advice in how to design and implement networks for optimized connectivity, with portability, scalability, performance and security for your specific workload requirements.
And don’t forget to swing by the Docker booth #2900B for more sessions, live demos and to get your container questions answered. Featured booth talks include:

Monday, 2:00 p.m. | Docker Enterprise Edition Demo
Tuesday, 11:00 a.m. | Modernize Traditional Apps with Docker and Save
Wednesday 2:00 p.m. | Docker Enterprise Edition and Cisco UCS CVD

No plans Tuesday night? Stop by the Las Vegas chapter of the Docker Meetup for a hands on tutorial on building hybrid Windows Server and Linux clusters and orchestrating hybrid Windows Server and Linux workloads together into a single application. More details and RSVP here.
The best way to get started containerizing is to start by modernizing legacy applications with Docker Enterprise Edition. In partnership with Cisco, an integrated program is available to accelerate the start of this journey in less than five days. Stop by the booth to learn more or visit www.docker.com/MTA. 

Check out #Docker Enterprise at Cisco Live in Las Vegas Booth 2900B Click To Tweet

More resources to get you started

Learn More about Cisco and Docker solution
Watch the on-demand webinar
Try Docker Enterprise Edition for free

The post Your Docker Agenda for Cisco Live 2017 – Booth #2900B appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Build and deploy hybrid applications in Azure using Docker Enterprise Edition

Don’t miss the Azure OpenDev event on June 21 2017 at 9am PDT.
Is your organization asking you to modernize a traditional app that uses old code to make it simpler to deploy and more scalable based on customer demand – what to do?
Scott Johnston, COO and Michael Friis, Product Manager at Docker will highlight two use cases that demonstrate how Docker and Microsoft are working together to help developers and IT-Pros build and deploy hybrid apps using Docker Enterprise Edition that span on-premises and Azure. Scott and Michael will also show how to use Docker to build microservices-based solutions on Azure and create agile software delivery pipelines in the cloud.
Scott Johnston’s session will cover the first use case: “Modernize Traditional Applications (MTA)” – a program that enables IT organizations to modernize legacy applications, transforming them in hybrid cloud deployments while simultaneously realizing substantial savings in their total cost of ownership (TCO). In partnership with companies such as Avanade and Microsoft, Docker is helping organizations containerize existing .NET Windows or Java Linux applications without modifying source code or re-architecting the applications. The applications can then be easily deployed to Azure in minutes.
This, addresses two major realities that IT organizations face: Existing applications consume 80% of most IT budgets, and IT organizations have to deliver on cloud migration initiatives. The heart of the program is methodology and tooling designed to make it easy for DevOps to deploy and manage newly-containerized applications onto hybrid cloud infrastructure. Put simply, Docker’s MTA program can help enterprise IT move forward on the path to digital transformation.
Michael Friis, will demo Image2Docker where you start with an VM image of an legacy Linux-based app and you run Image2Docker to extract Docker artifacts. You can then build and deploy the migrated application to Azure with Docker Enterprise Edition.
The second use case will demo how a developer can build a new Java Linux app on their laptop and deploy it to Azure using Docker Cloud and Docker Community Edition (CE) for Azure Container Service (ACS). The demo will start from running Docker CE with Swarm mode on Azure, registering Swarm with Docker Cloud, accessing Swarm with Docker ID and building, deploying a Java/Linux application.
Finally, watch Mark West, Senior Architect at MS IT sharing the success story of how the MS IT organization migrated 10 applications from two different business units into Docker containers running on the same host using Docker Enterprise Edition to Azure. All of this was possible with just a few Docker commands and didn’t require significant IT investments and approvals.

 
Continue your Docker journey with these helpful links:

Learn More about Modernize Traditional Applications
Try Docker Enterprise Edition for free
Learn More about Docker Enterprise Edition
Learn more about image2Docker for Linux and Windows Server

The post Build and deploy hybrid applications in Azure using Docker Enterprise Edition appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Docker and Booz Allen Hamilton Modernize Traditional Apps in Government IT

Existing applications and infrastructure account for the majority of IT spend in maintenance and support. Docker and Booz Allen Hamilton are partnering together to help Federal agencies modernize traditional apps with Docker Enterprise Edition (EE), deploy onto modern infrastructure to save infrastructure and operational costs, increase security and gain workload portability.
This program helps accelerate the path to modern microservices and infrastructure with containers:

First by containerizing the app in place and using container architecture to break up the app into smaller services over time
The full stack portability provided by Docker EE allows for workload consolidation for greater app density per server, accelerate hardware refresh cycles and cloud migration.
Lastly, Docker EE provides new levels of security for the legacy app. Scanning provides binary level visibility into components and their security profile for proactive remediation and configurable isolation properties can greatly reduce the attack surface area

View the webinar on demand here:

Here are some of the top Q&A from the session:
Q: What does Image2Docker exactly capture in the VM?
A: Image2Docker captures the application in the VM and pulls out what can be provided by the base image or the underlying linux/win kernel.
Q: When it comes to Docker, what do I do about other users who may be using a different Linux distro than I am?
A: Docker is supported on all major Linux distributions using a modern kernel. The containers are fully compatible between those distros and 100% portable from one OS host to another. View the supported OS list here.
Q: Do you have any metrics on how long an MTA engagement takes? Do you have it packaged as a week long effort or does it depend?
A: The MTA program is a 30 days program which is inclusive of one week onsite and three weeks remote. The program includes trial subscription of Docker Enterprise Edition (EE) and application migration services for 1-2 applications. The program is designed to demonstrate value very quickly while providing an opportunity to learn the Docker EE platform.
Q: What applications should I MTA and what about all the ones not covered in the Image2Docker tool? How do we deal with them?
The Image2Docker tool currently supports .NET and Java applications with more detectors coming soon. Give the Windows Server and Linux tools a try.
More Resources:

Learn More about Modernizing Traditional Apps
Register for an upcoming webinar
Try Docker Enterprise Edition for free

#Docker and @boozallen Modernize Traditional Apps in Government IT #dockerEE Click To Tweet

The post Docker and Booz Allen Hamilton Modernize Traditional Apps in Government IT appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Planning Your DockerCon Europe Week

DockerCon week is a busy week with so much information to absorb, people to meet and talks to attend. Here’s a quick agenda summary to make sure you know how to plan your travel and get the most out of your DockerCon Europe experience in Copenhagen.

Register for DockerCon Europe 2017
Monday 16 October
Monday is when the first attendees start arriving for DockerCon. Attendees who have signed up for Paid-Workshops or want to check in and pick up their badge and backpacks early should plan to be in Copenhagen by Monday morning. Monday is also a great day to get a jump start on meeting other attendees. You’ll be able to book Moby Mingles that help you connect with other attendees on topics you are both interested in learning or mentoring about.
Overview of Monday:

Paid Workshops (these are not included in your Full Conference Pass)
Registration Check-in
Moby Mingle
Evening Welcome reception in the Ecosystem Expo

Tuesday 17 October – Wednesday 18 October
Tuesday and Wednesday are full conference days. Each morning starts with a General Session presented by the Docker team and guest speakers to present the latest product announcements and use cases. Following the general sessions will be breakout sessions along with ample time to learn, connect and collaborate with other attendees and ecosystem sponsors exhibiting in the Ecosystem Expo Hall. 

Overview of Tuesday and Wednesday:

Moby Mingles
General Session
Breakout Sessions
Ecosystem Expo
After Party Tuesday evening
Cool Hacks General Session

Thursday 19 October
Moby Project Summit – NEW to DockerCon
The Moby Summit is a hands-on collaborative event open to all DockerCon attendees. The Summit is intended for distributed system experts and advanced container users who are actively maintaining, contributing or generally interested in the design and development of the Moby Project and it’s components.

This is a great opportunity for everyone attending the summit to learn, hack, collaborate and give feedback to drive the architectural decisions and roadmap behind these components and how they can be integrated together or with other components into assemblies.
Learn More about the Moby Project Summit

Learn more about DockerCon: 

Check out the DockerCon 2017 website to learn about speakers and sponsors
Watch the DockerCon 2017 videos
Sign up to receive DockerCon News
Submit a talk for DockerCon Europe

Time to book my @dockercon Europe 2017 ticket and travel to Copenhagen – Oct 16-19 #dockerconClick To Tweet

The post Planning Your DockerCon Europe Week appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/