Kategorie: Kubernetes

Docker Community Spotlight: Adina-Valentina Radulescu

Adina-Valentina Radulescu, a DevOps/Integration Engineer for Pentalog Romania, has been organizing meetups for not one but two meetup groups.
In February of last year, Adina founded Docker Brasov and Docker Timisoara, and has since done an amazing job creating and fostering a sense of belonging in her community. This month, we’re happy to shine the community spotlight on Adina to learn more about her Docker story.
Tell us about your first experience with Docker.
The first time I heard about Docker was back in 2014. I played around with Docker and I was impressed with the simplicity of integration so I wanted to learn more. I was able to attend DockerCon EU in 2015 in Barcelona where I completed some labs and attended the talks to learn as much as I could about Docker. It was a powerful feeling.
Why did you start Docker Brasov and Docker Timisoara?
I wanted to have a Docker sharing exchange experience when I get back in Romania. I relocated from Timisoara to a beautiful mountain city, Brasov. In Timisoara, I knew people and companies. In Brasov, I knew almost no one. This is why I decided to start the two groups so I could share what I had been learning, allow others to share their experience, and so we could stay up-to-date on Docker.

 
What do you love about the community and specifically the Docker community in Romania? What makes your community unique?
For both cities, what I love about the community is the people. Romanian people are extraordinary. In both groups, there are many different types of people with different backgrounds and experience. There are developers, Q&A managers, ops, students, freelancers etc. If someone can’t come, or has to cancel, they let me know. Our members respect each other and everyone is very warm and welcoming.
Now that you use Docker, how do you use it, and what do you use it for?
I use Docker both professionally and in my personal projects. At work, I help run all the tools that our development team needs in Docker. When IPs and network changes were made, the QA was affected first so they noticed communication issues that we could fix before getting into the release delivery. Since I brought Docker into the mix, the developers and QAs could actually focus on implementing and testing the application functionalitIes, not spending 50% of their time on system setups. It felt great that I was able to help them.
What are some aspects you love about organizing Docker meetups? 
I’m a people person so I really enjoy bringing the community together, meeting new people and sharing my experiences. I love meeting people who are talking about Docker and what I especially like about the Docker meetups, is how much I’m constantly learning. I enjoy planning the content and finding speakers that the groups would like to hear about.
What advice would you give to a new Docker organizer?
Passion is the key! Don’t be worried about your experience level. Use your passion to share and learn to organize great events. Docker puts together really great trainings and resources to get you started.
Try to identify passionate people in your community to help you out. Your contact for the venue can help with promotion, or someone might know a company who can sponsor food. I personally couldn’t have done it without the help of Ovidiu-Florin Bogdan who is very passionate about using Docker and who has been involved in the meetups from the beginning.
Adapt the meetup duration according to the participants needs. Either try to fit in a schedule (Timisoara) or don’t impose time limits (Brasov).

What do you do when you are not organizing meetup events?
I really like to stay active and travel. I particularly like Zumba and swimming. Every so often, I’m in my home city Resita organizing Coder Dojo meetups and mentoring kids.
Motto or personal mantra?

The best time is now.
If you are afraid of something you have to do it!  

Learn more about the Docker Community

Join the Docker Community Slack
Join your local Docker Meetup group 
Join the Docker Online Meetup group
Check out the Docker Playground for free hands-on labs
Attend the next DockerCon Europe in Copenhagen

Community Spotlight with @rav121rav: Read about her #Docker journey here: Click To Tweet

The post Docker Community Spotlight: Adina-Valentina Radulescu appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Demystifying the Open Container Initiative (OCI) Specifications

The Open Container Initiative (OCI) announced the completion of the first versions of the container runtime and image specifications this week. The OCI is an effort under the auspices of the Linux Foundation to develop specifications and standards to support container solutions. A lot of effort has gone into the building of these specifications over the past two years. With that in mind, let’s take a look at some of the myths that have arisen over the past two years.

Myth #1: The OCI is a replacement for Docker
Standards are important, but they are far from a complete production platform. Take for example, the World Wide Web. It  has evolved over the last 25 years and was built on core dependable standards like TCP/IP, HTTP and HTML. Using TCP/IP as an example, when enterprises coalesced around TCP/IP as a common protocol, it fueled the growth of routers and in particular – Cisco. However, Cisco became a leader in its market by focusing on differentiated features on its routing platform. We believe the parallel exists with the OCI specifications and Docker.
Docker is a complete production platform for developing, distributing, securing and orchestrating container-based solutions. The OCI specification is used by Docker, but it represents only about five percent of our code and a small part of the Docker platform concerned with the runtime behavior of a container and the layout of a container image. 
Myth #2: Products and projects already are certified to the OCI specifications
The runtime and image specifications have just released as 1.0 this week. However, the OCI certification program is still in development so companies cannot claim compliance, conformance or compatibility until certification is formally rolled out later this year.
The OCI certification working group is currently defining the standard so that products and open source projects can demonstrate conformance to the specifications. Standards and specifications are important for engineers implementing solutions, but formal certification is the only way to reassure customers that the technology they are working with is truly conformant to the standard.
Myth #3: Docker doesn’t support the OCI specifications work
Docker has a long history with contributing to the OCI. We developed and donated a majority of the OCI code and have been instrumental in defining the OCI runtime and image specifications as maintainers of the project. When the Docker runtime and image format quickly became the de facto standards after being released as open source in 2013, we thought it would be beneficial to donate the code to a neutral governance body to avoid fragmentation and encourage innovation. The goal was to provide a dependable and standardized specification so Docker contributed runc, a simple container runtime, as the basis of the runtime specification work, and later contributed the Docker V2 image specification as the basis for the OCI image specification work.
Docker developers like Michael Crosby and Stephen Day have been key contributors from the beginning of this work, ensuring Docker’s experience hosting and running billions of container images carries through to the OCI. When the certification working group completes its work, Docker will bring its products through the OCI certification process to demonstrate OCI conformance.
Myth #4: The OCI specifications are about Linux containers 
There is a misperception that the OCI is only applicable to Linux container technologies because it is under the aegis of the Linux Foundation. The reality is that although Docker technology started in the Linux world, Docker has been collaborating with Microsoft to bring our container technology, platform and tooling to the world of Windows Server. Additionally, the underlying technology that Docker has donated to the OCI is broadly applicable to  multi-architecture environments including Linux, Windows and Solaris and covers x86, ARM and IBM zSeries. 
Myth #5: Docker was just one of many contributors to the OCI
The OCI as an organization has a lot of supporting members representing the breadth of the container industry. That said, it has been a small but dedicated group of individual technologists that have contributed the time and technology to the efforts that have produced the initial specifications. Docker was a founding member of the OCI, contributing the initial code base that would form the basis of the runtime specification and later the reference implementation itself. Likewise, Docker contributed the Docker V2 Image specification to act as the basis of the OCI image specification.
Myth #6: CRI-O is an OCI project
CRI-O is an open source project in the Kubernetes incubator in the Cloud Native Computing Foundation (CNCF) – it is not an OCI project. It is based on an earlier version of the Docker architecture, whereas containerd is a direct CNCF project that is a larger container runtime that includes the runc reference implementation. containerd is responsible for image transfer and storage, container execution and supervision, and low-level functions to support storage and network attachments. Docker donated containerd to the CNCF with the support of the five largest cloud providers: Alibaba Cloud, AWS, Google Cloud Platform, IBM Softlayer and Microsoft Azure with a charter of being a core container runtime for multiple container platforms and orchestration systems.  
Myth #7: The OCI specifications are now complete 
While the release of the runtime and image format specifications is an important milestone, there’s still work to be done. The initial scope of the OCI was to define a narrow specification on which developers could depend for the runtime behavior of a container, preventing fragmentation in the industry, and still allowing innovation in the evolving container domain. This was later expanded to include a container image specification.
As the working groups complete the first stable specifications for runtime behavior and image format, new work is under consideration. Ideas for future work include distribution and signing. The next most important work for the OCI, however, is delivering on a certification process backed by a test suite now that the first specifications are stable.
Learn more about OCI and Open Source at Docker:

Read the blog post about the OCI Release of v1.0 Runtime and Image Format Specifications
Visit the Open Container Initiative website
Visit the Moby Project website
Attend DockerCon Europe 2017
Attend the Moby Summit LA alongside OSS NA

7 things to know about v1.0 of the #OCI runtime and image specifications Click To Tweet

The post Demystifying the Open Container Initiative (OCI) Specifications appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Docker Leads OCI Release of v1.0 Runtime and Image Format Specifications

Today marks an important milestone for the Open Container Initiative (OCI) with the release of the OCI v1.0 runtime and image specifications – a journey that Docker has been central in driving and navigating over the last two years. It has been our goal to provide low-level standards as building blocks for the community, customers and the broader industry. To understand the significance of this milestone, let’s take a look at the history of Docker’s growth and progress in developing industry-standard container technologies.
The History of Docker Runtime and Image Donations to the OCI
Docker’s image format and container runtime quickly emerged as the de facto standard following its release as an open source project in 2013. We recognized the importance of turning it over to a neutral governance body to fuel innovation and prevent fragmentation in the industry. Working together with a broad group of container technologists and industry leaders, the Open Container Project was formed to create a set of container standards and was launched under the auspices of the Linux Foundation in June 2015 at DockerCon. It became the Open Container Initiative (OCI) as the project evolved that Summer.
Docker contributed runc, a reference implementation for the container runtime software that had grown out of Docker employee Michael Crosby’s libcontainer project. runc is the basis for the runtime specification describing the life-cycle of a container and the behavior of a container runtime. runc is used in production across tens of millions of nodes, which is an order of magnitude more than any other code base. runc became the reference implementation for the runtime specification project itself, and continued to evolve with the project.  
Almost a year after work began on the runtime specification, a new working group formed to specify a container image format. Docker donated the Docker V2 Image Format to the OCI as the basis for the image specification. With this donation, the OCI defines the data structures — the primitives — that make up a container image. Defining the container image format is an important step for adoption, but it takes a platform like Docker to activate its value by defining and providing tooling on how to build images, manage them and ship them around. For example, things such as the Dockerfile are not included in the OCI specifications.
Title: Docker’s History of Contribution to the OCI
  
The Journey to Open Container Standards
The specifications have continued to evolve for two years now. Smaller projects have been spun out of the runc reference implementation as the code has been refactored, as well as support testing tools that will become the test suite for certification.
See the timeline above for details about Docker’s involvement in shaping OCI, which includes: creating runc, iterating on the runtime specification with the community, creating containerd to integrate runc in Docker 1.11, donating the Docker V2 Image Format to OCI as a base for the image format specification, implementing that specification in containerd so that this core container runtime covers both the runtime and image format standards, and finally donating containerd to the Cloud Native Computing Foundation (CNCF) and iterating on it towards a 1.0 alpha release this month.
Maintainers Michael Crosby and Stephen Day have lead the development of these specifications and have been instrumental in bringing v1.0 to fruition, alongside contributions from Alexander Morozov, Josh Hawn, Derek McGown and Aaron Lehmann, as well as Stephen Walli participating in the certification working group.
Docker remains committed to driving container standards, building a strong base at the layers where everyone agrees so that the industry can innovate at the layers that are still very differentiated.
Open Standards are Only a Piece of the Puzzle
Docker is a complete platform for creating, managing, securing, and orchestrating containers and container images. The vision has always been a base of industry standard specifications that support open source components or the plumbing of a container solution. The Docker platform sits above this layer – providing users and customers with a secure container management solution from development through production.  
The OCI runtime and image specifications become the dependable standards base that allow and encourage the greatest number of container solutions and at the same time, they do not restrict product innovation or shutout major contributors. To draw a comparison, TCP/IP, HTTP and HTML became the dependable standards base upon which the World Wide Web was built over the past 25 years. Companies continue to innovate with new tools, technologies and browsers on these standards. The OCI specifications provide the similar foundation for containers solutions going forward.
Open source projects also play a role in providing components for product development. The OCI runc reference implementation is used by the containerd project, a larger container runtime responsible for image transfer and storage, container execution and supervision, and low-level functions to support storage and network attachments. The containerd project was contributed by Docker to the CNCF and sits alongside other important projects to support cloud native computing solutions.
Docker uses containerd and more of its own core open source infrastructure elements like the LinuxKit, InfraKit and Notary projects to build and secure container solutions that become the Docker Community Edition tools. Users and organizations looking for complete container platforms that are holistic and provide container management, security, orchestration, networking and more can look to Docker Enterprise Edition.

This diagram highlights that the OCI specifications provide a layer of standards, implemented by a container runtime: containerd and runc. To assemble a full container platform such as Docker with full container lifecycle workflow, many other components are brought together: to manage infrastructure (InfraKit), provide an operating system (LinuxKit), deliver orchestration (SwarmKit), ensure security (Notary).

What’s Next for the OCI
We should celebrate the efforts of the developers as the runtime and image specifications are published. The next critical work to be done by the Open Container Initiative is to deliver a certification program to validate claims from implementers that their products and projects do indeed conform to the runtime and image specifications. The Certification Working Group has been putting together a program that in conjunction with a developing suite of test tools for both the runtime and image specifications will show how implementations fare against the standards.
At the same time, the developers of the current specifications are considering the next most important areas of container technology to specify. Work is underway around a common networking interface for containers in the Cloud Native Computing Foundation, but work to support signing and distribution are areas under consideration for the OCI.
Alongside the OCI and its members, Docker remains committed to standardizing container technology. The OCI’s mission is to give users and companies the baseline on which they can innovate in the areas of developer tooling, image distribution, container orchestration, security, monitoring and management. Docker will continue to lead the charge in innovation – not only with tooling that increases productivity and increases efficiencies, but also by empowering users, partners and customers to innovate as well.
Learn more about OCI and Open Source at Docker:

Read about the OCI specifications Myths
Visit the Open Container Initiative website
Visit the Moby Project website
Attend DockerCon Europe 2017
Attend the Moby Summit LA alongside OSS NA

Docker leads release of @OCI_ORG v1.0 container specifications to fuel ecosystem collaboration…Click To Tweet

The post Docker Leads OCI Release of v1.0 Runtime and Image Format Specifications appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Docker on Windows Webinar Q&A

Recently I presented Docker on Windows: from 101 to Modernizing .NET Apps, a live webinar on using Docker with Windows, and running .NET Framework apps in containers. The session was recorded and you can watch it on the Docker YouTube channel:

I start with the basics of Windows Docker containers, showing how to you can run containers from public images, and write Dockerfiles to package your own apps to run in containers.
Then I move onto Dockerizing a traditional ASP.NET WebForms app, showing you how to take existing apps and run them in Docker with no code changes, and then use the Docker platform to modernize the app – breaking features out of the monolithic codebase, running them in separate containers and using Docker to connect them.
I maxed out the session time (just like Mike with his Docker for the Sysadmin webinar), so here are the answers to questions raised in the session.
Q:  We have several servers hosting our frontend, some as middle tier hosting the services and we have some for the database. Shall we have a container for each service?
A: Docker doesn’t mandate any particular design, you can architect your move to Docker in the way that works best for you. You could start by packaging your whole web app into one Docker image and your service layer into another Docker image, without having to change source code.
You can run multiple web containers from your web image, and multiple service containers from your service image. That gives you failover, scale and zero-downtime deployments for updates. You also get better density – you won’t be allocating a set of servers to be the service layer, you have a single swarm and servers can run containers from different layers to get maximum compute utilization.
Docker containers can access other services on the network, so you can continue to use your existing database. That could be the first step in a roadmap to break out monolithic apps and run features in their own containers, which means you can scale, update and manage them separately.  Check out the Modernizing Traditional Apps labs for guidance.
Q:  What would be the proper way to isolate groups of containers in Docker, meaning having a set of containers for DEV and another set of containers for QA, running in the same Docker host or swarm? 
The best grouping mechanism is a Docker stack running in swarm mode. You don’t need a cluster of machines running Docker for swarm mode, you can run a single-node swarm for your non-production environments.
You define all the services for one application in a Docker compose file and deploy it to the swarm with docker stack deploy. You can manage the whole solution as one unit, having different stacks for different environments. Running in swarm mode also lets you scale services and use rolling updates for app changes, so you can practice deployments for production.
You could also have dedicated nodes in your swarm for each environment, using node labels and service constraints – so you could have two servers for integration, three for QA etc. but manage them all in the same swarm. Or run separate swarms and physically isolate your environments – you can run a single server in swarm mode.
The other option is to segment workloads by running them in separate Docker networks, if you’re running outside of swarm mode. That doesn’t work so well with Windows where there’s a single default NAT network.
Q:  Can you host .NET NT Services in a docker container? My .NET NT services also write to the windows Event-Viewer, how would this work between the host and the Service assuming I can run .NET NT services in a container.
Yes, with Windows Server Core as the base image you can run Windows Services. In your Dockerfile you would deploy the Windows Service with a script, like installing an MSI with msiexec. Then in your startup command you can use Start-Service to make sure the Windows Service is running when the container starts.
Docker doesn’t integrate directly with the Event Log in containers, but you can use a startup command which polls the Event Log and makes the entries visible from Docker – this is what Microsoft do with the Dockerfile for SQL Server.
Q: How is licensing handled for Windows in containers?
Licensing for containers is done at the host level, so if you have a Windows Server VM running 100 containers, you only pay one server licence for the VM.
Docker licensing is separate. Docker for Windows is a free Docker Community Edition, and runs on Windows 10 and Windows Server 2016. In production you get support with Docker Enterprise Edition, and the Windows Server 2016 licence includes Docker EE Basic so you can raise support tickets with Microsoft and have them escalated to Docker, Inc.
Q:  If I bring up 3 containers on a host, can I use host IP address or DNS name to access these, or do I have to use container IP address to access them?
You can publish container ports to the host when you run them, e.g. docker container run -d -p 80:80 microsoft/iis will run the IIS container with port 80 mapped to the host. Any external traffic to the host gets directed into the container. When you’re working locally on the Docker host, then you need to use the container IP addresses.
Inside the container it’s simpler. Service discovery is built into Docker. The platform has its own DNS server, so containers can reach other by container (or service) name. If you run SQL Server in a container called db then you can run an ASP.NET app in another container and use db as the server name in the database connection string. Docker resolves the container name to the IP address of the container transparently, whether the container is running on the same server, or a different server in a Docker swarm.
Q. Can we change the password of the “User ManagerContainerAdministrator”? Can we use this user account to run as our application service in the container?
No. ContainerAdministrator is a special virtual account, it doesn’t have a password. If you need to use an administrative account with a password, you can create one in the Dockerfile with the net user command, and add it to the admin group with net localgroup.
ContainerAdministrator is the default account when you run a container – so if your CMD instruction starts a console app, that app will run as ContainerAdministrator. If your app runs in the background as a Windows Service, then the account will be the service account, so ASP.NET apps run under application pool accounts.
Q:  Will the sample code be available after this?
Yes. The demos from the webinar were all based on the .NET Newsletter sample app on GitHub – dockersamples/newsletter-signup. It’s an ASP.NET WebForms app that’s been modernized using Docker, splitting features out from the original monolith into small, self-contained components.
Learn more about Docker on Windows:

Watch Docker for .NET Developers from DockerCon 2017
Try Image2Docker, a tool which extracts ASP.NET apps into Dockerfiles and deploy to Docker Enterprise Edition
Watch Escape from Your VMs, the DockerCon 2017 session on using Image2Docker
Come and join us in Copenhagen for DockerCon Europe 2017

 

#Docker on #Windows – from 101 to modernizing #dotnet apps. Q&A from the webinar with…Click To Tweet

The post Docker on Windows Webinar Q&A appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

The best way to learn Docker for Free: Play-With-Docker (PWD)

Last year at the Distributed System Summit in Berlin, Docker captains Marcos Nils and Jonathan Leibiusky started hacking on an in-browser solution to help people learn Docker. A few days later, Play-with-docker (PWD) was born. 
PWD is a Docker playground which allows users to run Docker commands in a matter of seconds. It gives the experience of having a free Alpine Linux Virtual Machine in browser, where you can build and run Docker containers and even create clusters in Docker Swarm Mode. Under the hood Docker-in-Docker (DinD) is used to give the effect of multiple VMs/PCs. In addition to the playground, PWD also includes a training site composed of a large set of Docker labs and quizzes from beginner to advanced level available at training.play-with-docker.com.
In case you missed it, Marcos and Jonathan presented PWD during the last DockerCon Moby Cool Hack session. Watch the video below for a deep dive into the infrastructure and roadmaps.

Over the past few months, the Docker team has been working closely with Marcos, Jonathan and other active members of the Docker community to add new features to the project and Docker labs to the training section.

PWD: the Playground
Here is a quick recap of what’s new with the Docker playground:
 
1.     PWD Docker Machine driver and SSH
As PWD success grew, the community started to ask if they could use PWD to run their own Docker workshops and trainings. So one of the first improvements made to the project was the creation of PWD Docker machine driver, which allows users to create and manage their PWD hosts easily through their favorite terminal including the option to use ssh related commands. Here is how it works:

 
2.     Adding support for file upload
Another cool feature brought to you by Marcos and Jonathan is the ability to upload your Dockerfile directly into your PWD windows with a simple drag and drop of your file in your PWD instance.

 
3.     Templated session
In addition to file upload, PWD also has a feature which lets you spin up a 5 nodes swarm in a matter of seconds using predefined templates.

 
4.      Showcasing your applications with Docker in a single click
Another cool feature that comes with PWD is its embeddable button that you can use in your sites to set up a PWD environment and deploy a compose stack right away and a chrome extension that adds the “Try in PWD” button to the most popular images in DockerHub. Here’s a short demo of the extension in action:

PWD: the Training Site
 A number of new labs are available on training.play-with-docker.com. Some notable highlights include two labs that were originally hands-on labs from DockerCon in Austin, and a couple that highlight new features that are stable in Docker 17.06CE:

Docker Networking Hands-on Lab
Docker Orchstration Hands-on Lab
Multi-stage builds
Docker swarm config files

All in all, there are now 36 labs, with more being added all the time. If you want to contribute a lab, check out the GitHub repo and get started.

PWD: the Use Cases
With the traffic to the site and the feedback we’ve received, it’s fair to say that PWD has a lot of traction right now. Here are some of the most common use-cases:

Try new features fast as it’s updated with the latest dev versions.
Set up clusters in no-time and launch replicated services.
Learn through it’s interactive tutorials: training.play-with-docker.com.
Give presentations at conferences and meetups.
Allow to run advanced workshops that’d usually require complex setups, such as Jérôme’s advanced Docker Orchestration workshop
Collaborate with community members to diagnose and detect issues.

Get involved with PWD:

Contribute to PWD by submitting PRs
Contribute to the PWD training site

Just starting to #learndocker? Check out PWD for free hands-on labs! Contributions welcome Click To Tweet

The post The best way to learn Docker for Free: Play-With-Docker (PWD) appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

How Watson Health Cloud Deploys Applications with Kubernetes

Today’s post is by Sandhya Kapoor, Senior Technologist, Watson Platform for Health, IBM For more than a year, Watson Platform for Health at IBM deployed healthcare applications in virtual machines on our cloud platform. Because virtual machines had been a costly, heavyweight solution for us, we were interested to evaluate Kubernetes for our deployments. Our design was to set up the application and data containers in the same namespace, along with the required agents using sidecars, to meet security and compliance requirements in the healthcare industry. I was able to run more processes on a single physical server than I could using a virtual machine. Also, running our applications in containers ensured optimal usage of system resources. To orchestrate container deployment, we are using Armada infrastructure, a Kubernetes implementation by IBM for automating deployment, scaling, and operations of application containers across clusters of hosts, providing container-centric infrastructure. With Kubernetes, our developers can rapidly develop highly available applications by leveraging the power and flexibility of containers, and with integrated and secure volume service, we can store persistent data, share data between Kubernetes pods, and restore data when needed. Here is a snapshot of Watson Care Manager, running inside a Kubernetes cluster: Before deploying an app, a user must create a worker node cluster. I can create a cluster using the kubectl cli commands or create it from a Bluemix dashboard. Our clusters consist of one or more physical or virtual machines, also known as worker nodes, that are loosely coupled, extensible, and centrally monitored and managed by the Kubernetes master. When we deploy a containerized app, the Kubernetes master decides where to deploy the app, taking into consideration the deployment requirements and available capacity in the cluster. A user makes a request to Kubernetes to deploy the containers, specifying the number of replicas required for high availability. The Kubernetes scheduler decides where the pods (groups of one or more containers) will be scheduled and which worker nodes they will be deployed on, storing this information internally in Kubernetes and etcd. The deployment of pods in worker nodes is updated based on load at runtime, optimizing the placement of pods in the cluster. Kubelet running in each worker node regularly polls the kube API server. If there is new work to do, kubelet pulls the configuration information and takes action, for example, spinning off a new pod. Process Flow:UCD – IBM UrbanCode Deploy is a tool for automating application deployments through your environments. WH Cluster – Kubernetes worker node.Usage of GitLab in the Process Flow: We stored all our artifacts in GitLab, which includes the Docker files that are required for creating the image, YAML files needed to create a pod, and the configuration files to make the Healthcare application run. GitLab and Jenkins interaction in the Process Flow:We use Jenkins for continuous integration and build automation to create/pull/retag the Docker image and push the image to a Docker registry in the cloud. Basically, we have a Jenkins job configured to interact with GitLab project to get the latest artifacts and, based on requirements, it will either create a new Docker image from scratch by pulling the needed intermediate images from Docker/Bluemix repository or update the Docker image. After the image is created/updated the Jenkins job pushes the image to a Bluemix repository to save the latest image to be pulled by UrbanCode Deploy (UCD) component. Jenkins and UCD interaction in the Process Flow:The Jenkins job is configured to use the UCD component and its respective application, application process, and the UCD environment to deploy the application. The Docker image version files that will be used by the UCD component are also passed via Jenkins job to the UCD component. Usage of UCD in the Process Flow:UCD is used for deployment and the end-to end deployment process is automated here. UCD component process involves the following steps:Download the required artifacts for deployment from the Gitlab.Login to Bluemix and set the KUBECONFIG based on the Kubernetes cluster used for creating the pods.Create the application pod in the cluster using kubectl create command.If needed, run a rolling update to update the existing pod. Deploying the application in Armada: Provision a cluster in Armada with <x> worker nodes. Create Kubernetes controllers for deploying the containers in worker nodes, the Armada infrastructure pulls the Docker images from IBM Bluemix Docker registry to create containers. We tried deploying an application container and running a logmet agent (see Reading and displaying logs using logmet container, below) inside the containers that forwards the application logs to an IBM cloud logging service. As part of the process, YAML files are used to create a controller resource for the UrbanCode Deploy (UCD). UCD agent is deployed as a DaemonSet controller, which is used to connect to the UCD server. The whole process of deployment of application happens in UCD. To support the application for public access, we created a service resource to interact between pods and access container services. For storage support, we created persistent volume claims and mounted the volume for the containers. UCD: IBM UrbanCode Deploy is a tool for automating application deployments through your environments. Armada: Kubernetes implementation of IBM. WH Docker Registry: Docker Private image registry. Common agent containers: We expect to configure our services to use the WHC mandatory agents. We deployed all ion containers.Reading and displaying logs using logmet container: Logmet is a cloud logging service that helps to collect, store, and analyze an application’s log data. It also aggregates application and environment logs for consolidated application or environment insights and forwards them. Metrics are transmitted with collectd. We chose a model that runs a logmet agent process inside the container. The agent takes care of forwarding the logs to the cloud logging service configured in containers. The application pod mounts the application logging directory to the storage space, which is created by persistent volume claim, and stores the logs, which are not lost even when the pod dies. Kibana is an open source data visualization plugin for Elasticsearch. It provides visualization capabilities on top of the content indexed on an Elasticsearch cluster. Exposing services with Ingress: Ingress controllers are reverse proxies that expose services outside cluster through URLs. They act as an external HTTP load balancer that uses a unique public entry point to route requests to the application. To expose our services to outside the cluster, we used Ingress. In Armada, if we create a paid cluster, an Ingress controller is automatically installed for us to use. We were able to access services through Ingress by creating a YAML resource file that specifies the service path.–Sandhya Kapoor, Senior Technologist, Watson Platform for Health, IBM 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 SlackGet involved with the Kubernetes project on GitHub
Quelle: kubernetes

Moby Summit alongside Open Source Summit North America

Since the Moby Project introduction at DockerCon 2017 in Austin last April, the Moby Community has been hard at work to further define the Moby project, improve its components (runC, containerd, LinuxKit, InfraKit, SwarmKit, Libnetwork and Notary) and fine processes and clear communication channels.
All project maintainers are developing these aspects in the open with the support of the community. Contributors are getting involved on GitHub, giving feedback on the Moby Project Discourse forum and asking questions on Slack. Special Interest Groups (SIGs) for the Moby Project components have been formed based on the Kubernetes model for Open Source collaboration. These SIGs ensure a high level of transparency and synchronization between project maintainers and a community of heterogeneous contributors.
In addition to these online channels and meetings, the Moby community hosts regular meetups and summits. Check out the videos and slides from the last DockerCon Moby May Summit and June Moby Summit to catch up on the latest project updates. The Moby Summit page on the Moby website contains the agenda and registration link for next Moby summit, as well as recaps of previous summit. 
The next Moby Summit will take place on September 14, 2017 in Los Angeles as part of the Open Source Summit North America. Following the success of the previous editions, we’ll keep the same format which consists of short technical talks / demos in the morning and Birds-of-a-Feather in the afternoon. We’re actively looking for people who can talk about their Moby Project use cases. Don’t hesitate to reach out to community@mobyproject.org if you’d like to give a talk or would like to cover a specific topic during the BoF sessions, or contribute to the agenda by sending a pull request to the Moby website repository.
 
Register for Moby Summit LA
 
  Learn more about the Moby Project:

Visit www.mobyproject.org
Join the #Moby-project channel on Slack
Check out the upcoming events in the Moby Community Calendar
Join the conversation on GitHub and Discourse

  

Attending #OSS17 in LA next September ? Join us at the @moby Summit on 9/14 #mobyprojectClick To Tweet

The post Moby Summit alongside Open Source Summit North America appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Securing the AtSea App with Docker Secrets

Passing application configuration information as environmental variables was once considered best practice in 12 factor applications. However, this practice can expose information in logs, can be difficult to track how and when information is exposed, third party applications can access this information. Instead of environmental variables, Docker implements secrets to manage configuration and confidential information.
Secrets are a way to keep information such as passwords and credentials secure in a Docker CE or EE with swarm mode. Docker manages secrets and securely transmits it to only those nodes in the swarm that need access to it. Secrets are encrypted during transit and at rest in a Docker swarm. A secret is only accessible to those services which have been granted explicit access to it, and only while those service tasks are running.
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. The previous post showed how to use multi-stage builds to create small and efficient images. In this post, I’ll demonstrate how secrets are implemented in the application.
Creating Secrets
Secrets can be created using the command line or with a Compose file. The AtSea application uses nginx as a reverse proxy secured with HTTPS. To accomplish this, I created a self-signed x509 certificate.
mkdir certs
openssl req -newkey rsa:4096 -nodes -sha256 -keyout certs/domain.key -x509 -days 365 -out certs/domain.crt
I then created secrets using the domain key and certificate for nginx.
docker secret create revprox_cert certs/domain.crt
docker secret create revprox_key certs/domain.key
I also used secrets to hold the PostgreSQL database password and a token for the payment gateway by making files that contained the password and token. For example, the postgres_password file contains the password ‘gordonpass’. In the compose file, I added the secrets:
secrets:
postgres_password:
file: ./devsecrets/postgres_password
payment_token:
file: ./devsecrets/payment_token
 I then set the database password secret,
 database:
   build: 
      context: ./database
   image: atsea_db
   environment:
     POSTGRES_USER: gordonuser
     POSTGRES_DB_PASSWORD_FILE: /run/secrets/postgres_password
     POSTGRES_DB: atsea
   ports:
     – “5432:5432″ 
   networks:
     – back-tier
   secrets:
     – postgres_password
and I make the postgres_password secret available to the application server.
appserver:
   build:
      context: .
      dockerfile: app/Dockerfile
   image: atsea_app
   ports:
     – “8080:8080″ 
     – “5005:5005″
   networks:
     – front-tier
     – back-tier
   secrets:
     – postgres_password
As you can see, you can set secrets at the command line and programmatically in the a compose file.
Docker Enterprise Edition (formerly known as Docker Datacenter) fully incorporates secrets management through creation, update and removal of secrets. In addition Docker EE supports authorization, rotation and auditing of secrets. Creating a secret in Docker Enterprise Edition is accomplished by clicking on the Resources tab and then the Secrets menu item.

Create the secret by entering the name and the value and clicking Create. In this example, I’m using the secret for the PostgreSQL password in the AtSea application.
 

Using Secrets
In order to use the Secret containing the certificate for nginx, I configured the nginx.conf file to point at the secret in the nginx container.
server {
  listen 443;
       ssl on;
       ssl_certificate /run/secrets/revprox_cert;
       ssl_certificate_key /run/secrets/revprox_key;
       server_name atseashop.com;
       access_log /dev/stdout;
       error_log /dev/stderr;

       location / {
           proxy_pass http://appserver:8080;
       }
   }

The AtSea application uses the postgres_password secret to connect to the database. This is done by reading the secret from the container and setting it to Spring-Boot’s DataSourceProperties class in the JpaConfiguration.java file.
// Set password to connect to postgres 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;
}

Learn more about Docker secrets:

Documentation
Command line
Docker Enterprise Editionr Secrets
Play with Docker Secrets hands-on lab
Docker Captain Alex Ellis’ Docker Secrets in Action
Why you shouldn’t use ENV variables for secret data

Securing AtSea with #Docker Secrets by @spara #dockersecurityClick To Tweet

The post Securing the AtSea App with Docker Secrets appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/