Spring Boot Development with Docker

The AtSea Shop is an example storefront application that can be deployed on different operating systems and can be customized to both your enterprise development and operational environments. In my last post, I discussed the architecture of the app. In this post, I will cover how to setup your development environment to debug the Java REST backend that runs in a container.
Building the REST Application
I used the Spring Boot framework to rapidly develop the REST backend that manages products, customers and orders tables used in the AtSea Shop. The application takes advantage of Spring Boot’s built-in application server, support for REST interfaces and ability to define multiple data sources. Because it was written in Java, it is agnostic to the base operating system and runs in either Windows or Linux containers. This allows developers to build against a heterogenous architecture.
Project setup
The AtSea project uses multi-stage builds, a new Docker feature, which allows me to use multiple images to build a single Docker image that includes all the components needed for the application. The multi-stage build uses a Maven container to build the the application jar file. The jar file is then copied to a Java Development Kit image. This makes for a more compact and efficient image because the Maven is not included with the application. Similarly, the React store front client is built in a Node image and the compile application is also added to the final application image.
I used Eclipse to write the AtSea app. If you want info on configuring IntelliJ or Netbeans for remote debugging, you can check out the the Docker Labs Repository. You can also check out the code in the AtSea app github repository.
I built the application by cloning the repository and imported the project into Eclipse by setting the Root Directory to the project and clicking Finish
    File > Import > Maven > Existing Maven Projects 
Since I used using Spring Boot, I took advantage of spring-devtools to do remote debugging in the application. I had to add the Spring Boot-devtools dependency to the pom.xml file.
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-devtools</artifactId>
</dependency>
Note that developer tools are automatically disabled when the application is fully packaged as a jar. To ensure that devtools are available during development, I set the <excludeDevtools> configuration to false in the spring-boot-maven build plugin:
<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <configuration>
                <excludeDevtools>false</excludeDevtools>
            </configuration>
        </plugin>
    </plugins>
</build>
This example uses a Docker Compose file that creates a simplified build of the containers specifically needed for development and debugging.
 version: “3.1”

services:
 database:
   build: 
      context: ./database
   image: atsea_db
   environment:
     POSTGRES_USER: gordonuser
     POSTGRES_DB: atsea
   ports:
     – “5432:5432″ 
   networks:
     – back-tier
   secrets:
     – postgres_password

 appserver:
   build:
      context: .
      dockerfile: app/Dockerfile-dev
   image: atsea_app
   ports:
     – “8080:8080″
     – “5005:5005″
   networks:
     – front-tier
     – back-tier
   secrets:
     – postgres_password

secrets:
 postgres_password:
   file: ./devsecrets/postgres_password
   
networks:
 front-tier:
 back-tier:
 payment:
   driver: overlay
 The Compose file uses secrets to provision passwords and other sensitive information such as certificates –  without relying on environmental variables. Although the example uses PostgreSQL, the application can use secrets to connect to any database defined by as a Spring Boot datasource. From JpaConfiguration.java:
 public DataSourceProperties dataSourceProperties() {
        DataSourceProperties dataSourceProperties = new DataSourceProperties();

    // Set password to connect to database using Docker secrets.
    try(BufferedReader br = new BufferedReader(new FileReader(“/run/secrets/postgres_password”))) {
        StringBuilder sb = new StringBuilder();
        String line = br.readLine();
        while (line != null) {
            sb.append(line);
            sb.append(System.lineSeparator());
            line = br.readLine();
        }
         dataSourceProperties.setDataPassword(sb.toString());
     } catch (IOException e) {
        System.err.println(“Could not successfully load DB password file”);
     }
    return dataSourceProperties;
}
Also note that the appserver opens port 5005 for remote debugging and that build calls the Dockerfile-dev file to build a container that has remote debugging turned on. This is set in the Entrypoint which specifies transport and address for the debugger.
ENTRYPOINT [“java”, 

“-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005″,”-jar”, 

“/app/AtSea-0.0.1-SNAPSHOT.jar”]
Remote Debugging
To start remote debugging on the application, run compose using the docker-compose-dev.yml file.
docker-compose -f docker-compose-dev.yml up –build
Docker will build the images and start the AtSea Shop database and appserver containers. However, the application will not fully load until Eclipse’s remote debugger attaches to the application. To start remote debugging you click on Run > Debug Configurations …
Select Remote Java Application then press the new button to create a configuration. In the Debug Configurations panel, you give the configuration a name, select the AtSea project and set the connection properties for host and the port to 5005. Click Apply > Debug.  

The appserver will start up.
appserver_1|2017-05-09 03:22:23.095 INFO 1 — [main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http)

appserver_1|2017-05-09 03:22:23.118 INFO 1 — [main] com.docker.atsea.AtSeaApp                : Started AtSeaApp in 38.923 seconds (JVM running for 109.984)
To test remote debugging set a breakpoint on ProductController.java where it returns a list of products.

You can test it using curl or your preferred tool for making HTTP requests:
curl -H “Content-Type: application/json” -X GET  http://localhost:8080/api/product/
Eclipse will switch to the debug perspective where you can step through the code.

The AtSea Shop example shows how easy it is to use containers as part of your normal development environment using tools that you and your team are familiar with. Download the application to try out developing with containers or use it as basis for your own Spring Boot REST application.
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
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

Developing the AtSea app with #Docker and #SpringBoot by @sparaClick To Tweet

The post Spring Boot Development with Docker appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Kubernetes: a monitoring guide

Today’s post is by Jean-Mathieu Saponaro, Research & Analytics Engineer at Datadog, discussing what Kubernetes changes for monitoring, and how you can prepare to properly monitor a containerized infrastructure orchestrated by Kubernetes.Container technologies are taking the infrastructure world by storm. While containers solve or simplify infrastructure management processes, they also introduce significant complexity in terms of orchestration. That’s where Kubernetes comes to our rescue. Just like a conductor directs an orchestra, Kubernetes oversees our ensemble of containers—starting, stopping, creating, and destroying them automatically to keep our applications humming along.Kubernetes makes managing a containerized infrastructure much easier by creating levels of abstractions such as pods and services. We no longer have to worry about where applications are running or if they have enough resources to work properly. But that doesn’t change the fact that, in order to ensure good performance, we need to monitor our applications, the containers running them, and Kubernetes itself.Rethinking monitoring for the Kubernetes eraJust as containers have completely transformed how we think about running services on virtual machines, Kubernetes has changed the way we interact with containers. The good news is that with proper monitoring, the abstraction levels inherent to Kubernetes provide a comprehensive view of your infrastructure, even if the containers and applications are constantly moving. But Kubernetes monitoring requires us to rethink and reorient our strategies, since it differs from monitoring traditional hosts such as VMs or physical machines in several ways.Tags and labels become essentialWith containers and their orchestration completely managed by Kubernetes, labels are now the only way we have to interact with pods and containers. That’s why they are absolutely crucial for monitoring since all metrics and events will be sliced and diced using labels across the different layers of your infrastructure. Defining your labels with a logical and easy-to-understand schema is essential so your metrics will be as useful as possible.There are now more components to monitorIn traditional, host-centric infrastructure, we were used to monitoring only two layers: applications and the hosts running them. Now with containers in the middle and Kubernetes itself needing to be monitored, there are four different components to monitor and collect metrics from.Applications are constantly movingKubernetes schedules applications dynamically based on scheduling policy, so you don’t always know where applications are running. But they still need to be monitored. That’s why using a monitoring system or tool with service discovery is a must. It will automatically adapt metric collection to moving containers so applications can be continuously monitored without interruption.Be prepared for distributed clustersKubernetes has the ability to distribute containerized applications across multiple data centers and potentially different cloud providers. That means metrics must be collected and aggregated among all these different sources.  For more details about all these new monitoring challenges inherent to Kubernetes and how to overcome them, we recently published an in-depth Kubernetes monitoring guide. Part 1 of the series covers how to adapt your monitoring strategies to the Kubernetes era.Metrics to monitorWhether you use Heapster data or a monitoring tool integrating with Kubernetes and its different APIs, there are several key types of metrics that need to be closely tracked:Running pods and their deploymentsUsual resource metrics such as CPU, memory usage, and disk I/OContainer-native metricsApplication metrics for which a service discovery feature in your monitoring tool is essential All these metrics should be aggregated using Kubernetes labels and correlated with events from Kubernetes and container technologies. Part 2 of our series on Kubernetes monitoring guides you through all the data that needs to be collected and tracked.Collecting these metricsWhether you want to track these key performance metrics by combining Heapster, a storage backend, and a graphing tool, or by integrating a monitoring tool with the different components of your infrastructure, Part 3, about Kubernetes metric collection, has you covered. Anchors aweigh!Using Kubernetes drastically simplifies container management. But it requires us to rethink our monitoring strategies on several fronts, and to make sure all the key metrics from the different components are properly collected, aggregated, and tracked. We hope our monitoring guide will help you to effectively monitor your Kubernetes clusters. Feedback and suggestions are more than welcome. –Jean-Mathieu Saponaro, Research & Analytics Engineer, DatadogGet 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

Docker Federal Summit Recap and videos

On May 2nd, Docker returned to the Newseum to host the second annual Docker Federal Summit.  This one day event is designed to bring government agency developers, IT ops, program leaders and the ecosystem together to share and learn about the trends driving change in IT from containers, cloud and devops.  We expanded the agenda this year two tracks, with presentations from Docker, ecosystem partners, agency and community leaders to drive discussions, technology deep dives and hands on tutorials.
View the general session replay here:

General session table of content and slides

13:05 Iain Gray, SVP Customer Success discusses how Docker delivers a unique secure supply chain for all applications and infrastructure
33:35 Nathan McCauley, Director Security Engineering discusses the principles of least privilege design on which Docker is built
55:30 Modernize Traditional Apps to gain portability, security and efficiency without changing source code
59:13 Banjot Chanana, Senior Director Products delivers an overview and demo of Docker Enterprise Edition

In addition, the following breakout sessions dove deeper into pragmatic advice, security, development, cloud and compliance.

Lessons Learned from Deploying Containers in Production featuring a panel discussion with Booz Allen Hamilton, JIDO, GSA and USCIS
Scaling and Securing Applications on Your Terms featuring Doug Gebert, HPE Deputy CTO for DISA and DoD
Supercharge Modern App Development with Azure Government and Docker featuring Eddie Villalba and Steve Michelotti
Federal Compliance Panel Discussion featuring Andrew Weiss, Susie Adams, James Scott and Greg Elin
Docker Secure Substrate for Container Apps featuring Riyaz Faizullabhoy and Andy Clemenko

For hands on training, the Federal Summit offered tutorials on Modernizing .NET apps, Docker Orchestration and Deploying Apps with Docker Enterprise Edition. These hands on labs are now available publicly for anyone interested in learning more about Docker.
Last but not least – Thank you to our event sponsors.

Continue your Docker journey with these helpful links

Try Docker Enterprise Edition for free
Learn more about Docker in Government
Register for an upcoming Docker webinar

 

#DockerFedSummit videos and tutorials now available onlineClick To Tweet

The post Docker Federal Summit Recap and videos appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Kargo 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 Kargo?Making Kubernetes operationally strong is a widely held priority and I track many deployment efforts around the project. The incubated Kargo 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 Kargo 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 Kargo 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 Kargo 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 Kargo 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 Kargo 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, Kargo 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

Dancing at the Lip of a Volcano: The Kubernetes Security Process – Explained

Editor’s note: Today’s post is by Jess Frazelle of Google and Brandon Philips of CoreOS about the Kubernetes security disclosures and response policy. Software running on servers underpins ever growing amounts of the world’s commerce, communications, and physical infrastructure. And nearly all of these systems are connected to the internet; which means vital security updates must be applied rapidly. As software developers and IT professionals, we often find ourselves dancing on the edge of a volcano: we may either fall into magma induced oblivion from a security vulnerability exploited before we can fix it, or we may slide off the side of the mountain because of an inadequate process to address security vulnerabilities. The Kubernetes community believes that we can help teams restore their footing on this volcano with a foundation built on Kubernetes. And the bedrock of this foundation requires a process for quickly acknowledging, patching, and releasing security updates to an ever growing community of Kubernetes users. With over 1,200 contributors and over a million lines of code, each release of Kubernetes is a massive undertaking staffed by brave volunteer release managers. These normal releases are fully transparent and the process happens in public. However, security releases must be handled differently to keep potential attackers in the dark until a fix is made available to users.We drew inspiration from other open source projects in order to create the Kubernetes security release process. Unlike a regularly scheduled release, a security release must be delivered on an accelerated schedule, and we created the Product Security Team to handle this process.This team quickly selects a lead to coordinate work and manage communication with the persons that disclosed the vulnerability and the Kubernetes community. The security release process also documents ways to measure vulnerability severity using the Common Vulnerability Scoring System (CVSS) Version 3.0 Calculator. This calculation helps inform decisions on release cadence in the face of holidays or limited developer bandwidth. By making severity criteria transparent we are able to better set expectations and hit critical timelines during an incident where we strive to:Respond to the person or team who reported the vulnerability and staff a development team responsible for a fix within 24 hoursDisclose a forthcoming fix to users within 7 days of disclosureProvide advance notice to vendors within 14 days of disclosureRelease a fix within 21 days of disclosureAs we continue to harden Kubernetes, the security release process will help ensure that Kubernetes remains a secure platform for internet scale computing. If you are interested in learning more about the security release process please watch the presentation from KubeCon Europe 2017 on YouTube and follow along with the slides. If you are interested in learning more about authentication and authorization in Kubernetes, along with the Kubernetes cluster security model, consider joining Kubernetes SIG Auth. We also hope to see you at security related presentations and panels at the next Kubernetes community event: CoreOS Fest 2017 in San Francisco on May 31 and June 1.As a thank you to the Kubernetes community, a special 25 percent discount to CoreOS Fest is available using k8s25code or via this special 25 percent off link to register today for CoreOS Fest 2017. –Brandon Philips of CoreOS and Jess Frazelle of GooglePost 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 SlackGet involved with the Kubernetes project on GitHub
Quelle: kubernetes

Developing a Spring Boot app on Docker: The AtSea Demo App

This is the first of a series of blog posts that demonstrates using Docker to develop a typical web application and deploying it in production. For DockerCon 2017, we wanted to build a new demo application that would demonstrate the flexibility of using Docker in development as well as showcase the features of Docker in a production environment. The result was the AtSea Shop, a storefront application that can be deployed on different operating systems and can be customized to both your enterprise development and operational environment.

A Hybrid Architecture
The team decided on a few ground rules. First, we wanted to use modern components commonly used in enterprise applications. We decided to build a Java application using the Spring Boot framework. The web client is a javascript application written using React as a framework.  Second, the application should be able to use any relational database and that it could be deployed on a Linux or Windows environment or cluster. Finally, the team wanted to show the process from development to deployment including building the application, implementing security, and deploying the application.

The application combines a typical Java n-tier architecture that uses Spring Boot’s web MVC framework for the REST API and Spring Data to manage database operations. We chose PostgreSQL for the database, but the application can use any database defined by Spring Data. The storefront client was developed separately using React, and added to the AtSea jar file. Finally, we used a bash script to simulate a payment gateway that uses secrets to authorize transactions.
Although the application is deployed in an n-tier configuration, with the javascript client included in the application jar, each of these components could be deployed separately in a microservice architecture.
Developing and Deploying with Docker
Developing an application with a distributed team can be challenging. Docker provides significant advantages when developing an application by:

enabling migration to microservices
establishing a consistent deployment environment
developers can use familiar tools and IDEs
allowing for rapid implementation and testing of ideas
simplifying the process to deploying to production
easily develop polyglot applications with multiple programming languages
building in security tools
enabling quick deployment of your application

You can see the code for the AtSea app in our new Docker Samples organization on GitHub, where we share our sample applications.
In following articles, we’ll go into depth on the following topics

developing with Eclipse and Docker
using multistage builds to create containers
implementing container security using secrets
deploying the application to a cluster
running the application in Windows containers

While you’re waiting, check out these developer resources and videos from Dockercon 2017.

AtSea Shop demo
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

Learn how to Develop a @SpringBoot app on #Docker: The AtSea Demo AppClick To Tweet

The post Developing a Spring Boot app on Docker: The AtSea Demo App appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Docker at Microsoft Build 2017

Build is Microsoft’s premier developer event, run annually. This year Docker, Inc. and containers were everywhere, starting with a dedicated container pre-day, then with constant traffic to the Docker booth, and many shared container success stories.

Container Fest Pre-Day
Build is usually a three-day event, but this year saw the very first pre-day – run jointly by Docker and Microsoft. “Container Fest” was a whole-day event focused on containers and Docker, running on Windows and Linux, on-premises and in Azure.
There were 12 sessions throughout the day, presented by engineers and architects from Microsoft and Docker, Inc. They covered everything from the internals of Docker on Windows Server, through modernizing .NET Framework apps with Docker, to the options for running Docker containers on Azure.
A popular first step for modernizing traditional Windows applications is to use Image2Docker, which we demonstrated at the event. Image2Docker can extract existing applications from Windows machines into Dockerfiles, so you can automate the conversion of your app landscape to Docker. You can see Image2Docker in action from our session at DockerCon:

Over 300 people were at the Container Fest pre-day, and when the sessions had finished, they stayed on to run through the Hands-On Labs from DockerCon. Just like at DockerCon, we provisioned virtual machines in Azure for attendees to use for working through the labs, and the experts were available for help and advice.
The DockerCon 2017 labs cover a range of topics, including orchestration and networking, Docker Enterprise Edition and Docker Cloud, and running Docker containers on Windows. The labs are open source on GitHub now, as part of the main Docker labs repo. If you’re looking to get started with Docker on Windows, these labs give you a great roadmap:

Windows 101 – learn the basics of Docker and Windows containers
Modernize .NET Apps, for Ops – see how to package an ASP.NET app as a Docker image
Modernize .NET Apps, for Devs – modernize an ASP.NET by breaking features out into Docker containers
SQL Server – learn how to run SQL Server in Docker containers and package up a custom database schema into a Docker image

Partner Hub
Hundreds of attendees dropped into the Docker booth in the MS Build Conference Hub expo area to ask for help and advice, tell us about their Docker journey, or just to say Hi. The level of Docker experience was everything from complete beginners to folks running production workloads on Docker Enterprise Edition.
We had some videos running on loop, which were people found very useful – and these are on YouTube so you can check them out yourself. To start, there’s the Docker on Windows 101, which introduces you to how containers work on Windows:

And for the journey into production, we have a tour around Docker Datacenter, the Containers-as-a-Service (CaaS) platform available with Docker Enterprise Edition standard and advanced. 

The crack team from Docker were kept busy through the whole event, had a great time, and are thoroughly looking forward to next year.
Learn More:

Try out the DockerCon 2017 Hands-On Labs for yourself
Get the Modernize Traditional Apps kit to plan your MTA program with Docker
Scott Guthrie from Microsoft is on a European tour – Docker will be joining in Amsterdam, London and Dublin
Try out Image2Docker for Windows and Image2Docker for Linux
Learn more about Docker and Microsoft together

Highlights from #MSBuild: Internals of #Docker on Windows, modernizing .NET framework apps &…Click To Tweet

The post Docker at Microsoft Build 2017 appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

The Latest Docker Certified Container and Plugins for March and April 2017

The Docker Certification Program provides a way for technology partners to validate and certify their software or plugin as a container for use on the Docker Enterprise Edition platform.  Since the initial launch of the program in March, more Containers and Plugins have been certified and available for download.
 
Certified Containers and Plugins are technologies that are built with best practices as Docker containers, tested and validated against the Docker Enterprise Edition platform and APIs, pass security requirements, reviewed by Docker partner engineering and cooperatively supported by both Docker and the partner. Docker Enterprise Edition and Certified Technology provide assurance and support to businesses for their critical application infrastructure.
Check out the latest Docker Certified technologies to the Docker Store:

Dynatrace provides monitoring Docker applications and Docker clusters out of the box.
{code} by Dell EMC certified a number of REX-ray volume plugins for the following: REX-Ray for AWS EFS, REX-Ray for AWS EBS, REX-Ray for S3FS, REX-Ray for Isilon, REX-Ray for GCE and REX-Ray for ScaleIO.
HPE OpsBridge Agent provides monitoring of Docker applications with HPE Operations Bridge.
CoScale Agent provides a lightweight solution for monitoring the performance of your Docker containers and microservices in production.
NexentaEdge Docker NFS Volume Plug-In for the Nexenta Scale-Out High Performance Multi-Service Solution with Cluster-Wide Deduplication and Compression.
Oracle: As announced at DockerCon, many Oracle products are now available on Docker Store including Oracle Coherence, Oracle WebLogic Server, Oracle Java 8 SE (Server JRE), and Oracle Instant Client.
VMware Vsphere Volume Service for Docker enables the ability to run stateful container applications on VMware vSphere.
Weaveworks Network Plugin provides simple, resilient multi-host Docker networking.

Check Visit Docker Store regularly to browse and download the latest Certified Containers and Plugins. Interested in publishing? Sign up here to start posting to Docker Store.
 

The latest Docker Certified Containers and Plugins on #Docker StoreClick To Tweet

Continue your Docker journey with these helpful links:

Try Docker Enterprise Edition for free
Browse the Docker Store for Certified Containers and Certified Plugins
Sign up to become a Docker Store Publisher

The post The Latest Docker Certified Container and Plugins for March and April 2017 appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

DockerCon Hands-on Labs now online

One of more popular activities at DockerCon is our Hands-on Labs, where you can learn to use the Docker tools you see announced on stage, or talked about in the breakout sessions. This year we had eight labs for people to work through, ranging from 20 minutes to an hour in length.

We’ve now moved these apps into the Docker Labs Repo so that everyone can use them. The Docker Labs Repo is where we put a bunch of learning content for people who want to learn Docker, from beginner to advanced security and networking labs.
Here are the new labs:
Continuous Integration With Docker Cloud
In this lab, you will learn how to configure a continuous integration (CI) pipeline for a web application using Docker Cloud’s automated build features.
Docker Swarm Orchestration Beginner and Advanced
In this lab, you will play around with the container orchestration features of Docker. You will deploy a simple application to a single host and learn how that works. Then, you will configure Docker Swarm Mode, and learn to deploy the same simple application across multiple hosts. You will then see how to scale the application and move the workload across different hosts easily.
Securing Apps with Docker EE Advanced / Docker Trusted Registry
In this lab, you will integrate Docker EE Advanced in to your development pipeline. You will build your application from a Dockerfile and push your image to the Docker Trusted Registry (DTR). DTR will scan your image for vulnerabilities so they can be fixed before your application is deployed.
Docker Networking
In this lab you will learn about key Docker Networking concepts. You will get your hands dirty by going through examples of a few basic networking concepts, learn about Bridge and Overlay networking, and finally learning about the Swarm Routing Mesh.
Windows Docker Containers 101
Docker runs natively on Windows 10 and Windows Server 2016. In this lab you’ll learn how to package Windows applications as Docker images and run them as Docker containers. You’ll learn how to create a cluster of Docker servers in swarm mode, and deploy an application as a highly-available service.
Modernize .NET Apps – for Devs
You can run full .NET Framework apps in Docker using the Windows Server Core base image from Microsoft. That image is a headless version of Windows Server 2016, so it has no UI but it has all the other roles and features available. Building on top of that there are also Microsoft images for IIS and ASP.NET, which are already configured to run ASP.NET and ASP.NET 3.5 apps in IIS.
This lab steps through porting an ASP.NET WebForms app to run in a Docker container on Windows Server 2016. With the app running in Docker, you can easily modernize it – and in the lab you’ll add new features quickly and safely by making use of the Docker platform.
Modernize .NET Apps – for Ops
You’ll already have a process for deploying ASP.NET apps, but it probably involves a lot of manual steps. Work like copying application content between servers, running interactive setup programs, modifying configuration items and manual smoke tests all add time and risk to deployments.
In Docker, the process of packaging applications is completely automated, and the platform supports automatic update and rollback for application deployments. You can build Docker images from your existing application artifacts, and run ASP.NET apps in containers without going back to source code.
This lab is aimed at ops and system admins. It steps through packaging an ASP.NET WebForms app to run in a Docker container on Windows 10 or Windows Server 2016. It starts with an MSI and ends by showing you how to run and update the application as a highly-available service on Docker swarm.
So check out these labs, or head on over the Docker Labs repo and check out the other great content we have there. And if that doesn’t satisfy you desire for hands-on learning, come to DockerCon Europe in October, where we’ll have yet more labs for you to try out the very latest in Docker tech.

More Hands-on Learning with the #DockerCon Labs, now available to allClick To Tweet

More Resources

Check out the Docker Labs repo for this and many more tutorials
Register for an upcoming Docker Webinar
Attend an upcoming Docker event near you

The post DockerCon Hands-on Labs now online appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Mentorship in the Docker Community: How you can get involved

Mentorship is an important part of the Docker Community. Over the past few global event series like the Docker Birthday #3 and Mentor week last year, advanced users attended their local event and helped attendees work through training materials. As interest in mentorship continues to grow, we’re excited to grow our programs and provide more opportunities for the community to get involved.

New this year at DockerCon, we organized a Mentor Summit for attendees to learn the ins and outs of being an awesome mentor both in industry and in the Docker Community. Check out the talks below and learn how you can get involved.
Anna Osswoski – How to Mentor and be a Great One

View Anna’s slides here.
Sebastiaan van Stijn – How To Contribute to Open Source

Jérôme Petazzoni – A DockerCon 2017 Recap: give a talk in your local community

Are you an advanced Docker user? Join the Docker Mentor Group!
With over 280 Docker Meetup groups worldwide, the Docker online Community Group + Slack, and other programs, there is always an opportunity for collaboration and knowledge sharing. Mentors should have experience working with Docker Engine, Docker Networking, Docker Hub, Docker Machine, Docker Orchestration and Docker Compose.
Sign up as a mentor!
Learn about Mentorship in the Docker Community:

Join the online Community Mentor Group
Watch the DockerCon Recap Online Meetup recording
Review Docker Meetup Content (DMC) DockerCon 2017 Highlights!

Learn how to be a great mentor in the #docker community! Talks by @jpetazzo @OssAnna16 &…Click To Tweet

The post Mentorship in the Docker Community: How you can get involved appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/