Kategorie: Kubernetes

Designing Your First Application in Kubernetes, Part 4: Configuration

I reviewed the basic setup for building applications in Kubernetes in part 1 of this blog series, and discussed processes as pods and controllers in part 2. In part 3, I explained how to configure networking services in Kubernetes to allow pods to communicate reliably with each other. In this installment, I’ll explain how to identify and manage the environment-specific configurations expected by your application to ensure its portability between environments.

Factoring out Configuration
One of the core design principles of any containerized app must be portability. We absolutely do not want to reengineer our containers or even the controllers that manage them for every environment. One very common reason why an application may work in one place but not another is problems with the environment-specific configuration expected by that app.
A well-designed application should treat configuration like an independent object, separate from the containers themselves, that’s provisioned to them at runtime. That way, when you move your app from one environment to another, you don’t need to rewrite any of your containers or controllers; you simply provide a configuration object appropriate to this new environment, leaving everything else untouched.
When we design applications, we need to identify what configurations we want to make pluggable in this way. Typically, these will be environment variables or config files that change from environment to environment, such as access tokens for different services used in staging versus production or different port configurations.
Decision #4: What application configurations will need to change from environment to environment?
From our web app example, a typical set of configs would include the access credentials for our database and API (of course, you’d never use the same ones for development and production environments), or a proxy config file if we chose to include a containerized proxy in front of our web frontend.
Once we’ve identified the configs in our application that should be pluggable, we can enable the behavior we want by using Kubernetes’ system of volumes and configMaps.
In Kubernetes, a volume can be thought of as a filesystem fragment. Volumes are provisioned to a pod and owned by that pod. The file contents of a volume can be mounted into any filesystem path we like in the pod’s containers.
I like to think of the volume declaration as the interface between the environment-specific config object and the portable, universal application definition. Your volume declaration will contain the instructions to map a set of external configs onto the appropriate places in your containers.
ConfigMaps contain the actual contents you’re going to use to populate a pod’s volumes or environment variables. They contain-key value pairs describing either files and file contents, or environment variables and their values. ConfigMaps typically differ from environment to environment. For example, you will probably have one configMap for your development environment and another for production—with the correct variables and config files for each environment. 

The configMap and Volume interact to provide configuration for containers.

Checkpoint #4: Create a configMap appropriate to each environment. 
Your development environment’s configMap objects should capture the environment-specific configuration you identified above, with values appropriate for your development environment. Be sure to include a volume in your pod definitions that uses that configMap to populate the appropriate config files in your containers as necessary. Once you have the above set up for your development environment, it’s simple to create a new configMap object for each downstream environment and swap it in, leaving the rest of your application unchanged.
Advanced Topics
Basic configMaps are a powerful tool for modularizing configuration, but some situations require a slightly different approach.

Secrets in Kubernetes are like configMaps in that they package up a bunch of files or key/value pairs to be provisioned to a pod. However, secrets offer added security guarantees around encryption data management. They are the more appropriate choice for any sensitive information, like passwords, access tokens or other key-like objects.

To learn more about configuring Kubernetes and related topics: 

Check out Play with Kubernetes, powered by Docker.
Read the Kubernetes documentation on Volumes. 
Read the Kubernetes documentation on ConfigMaps.

We will also be offering training on Kubernetes starting in early 2020. In the training, we’ll provide more specific examples and hands on exercises.To get notified when the training is available, sign up here:
Get Notified About Training

Designing Your First App in #Kubernetes, Part 4 — Managing Environment-Specific ConfigurationsClick To Tweet

The post Designing Your First Application in Kubernetes, Part 4: Configuration appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Designing Your First Application in Kubernetes, Part 3: Communicating via Services

I reviewed the basic setup for building applications in Kubernetes in part 1 of this blog series, and discussed processes as pods and controllers in part 2. In this post, I’ll explain how to configure networking services in Kubernetes to allow pods to communicate reliably with each other.
Setting up Communication via Services 
At this point, we’ve deployed our workloads as pods managed by controllers, but there’s no reliable, practical way for pods to communicate with each other, nor is there any way for us to visit any network-facing pod from outside the cluster. Kubernetes networking model says that any pod can reach any other pod at the target pod’s IP by default, but discovering those IPs and maintaining that list while pods are potentially being rescheduled — resulting in them getting an entirely new IP — by hand would be a lot of tedious, fragile work.
Instead, we need to think about Kubernetes services when we’re ready to start building the networking part of our application. Kubernetes services provide reliable, simple networking endpoints for routing traffic to pods via the fixed metadata defined in the controller that created them, rather than via unreliable pod IPs. For simple applications, two services cover most use cases: clusterIP and nodePort services. This brings us to another decision point:
Decision #3: What kind of services should route to each controller? 
For simple use cases, you’ll choose either clusterIP or nodePort services. The simplest way to decide between them is to determine whether the target pods are meant to be reachable from outside the cluster or not. In our example application, our web frontend should be reachable externally so users can access our web app.
In this case, we’d create a nodePort service, which would route traffic sent to a particular port on any host in your Kubernetes cluster onto our frontend pods (Swarm fans: this is functionally identical to the L4 mesh net).
A Kubernetes nodePort service allows external traffic to be routed to the pods.
For our private API + database pods, we may only want them to be reachable from inside our cluster for security and traffic control purposes. In this case, a clusterIP service is most appropriate. The clusterIP service will provide an IP and port which only other containers in the cluster may send traffic to, and have it forwarded onto the backend pods.
A Kubernetes clusterIP service only accepts traffic from within the cluster.
Checkpoint #3: Write some yaml and verify routing
Write some Kubernetes yaml to describe the services you choose for your application and make sure traffic gets routed as you expect.
Advanced Topics
The simple routing and service discovery above will get pods talking to other pods and allow some simple ingress traffic, but there are many more advanced patterns you’ll want to learn for future applications:

Headless Services can be used to discover and route to specific pods; you’ll use them for stateful pods declared by a statefulSet controller.
Kube Ingress and IngressController objects provide managed proxies for doing routing at layer 7 and implementing patterns like sticky sessions and path-based routing.
ReadinessProbes work exactly like the healthchecks mentioned above, but instead of managing the health of containers and pods, they monitor and respond to their readiness to accept network traffic.
NetworkPolicies allow for the segmentation of the normally flat and open Kubernetes network, allowing you to define what ingress and egress communication is allowed for a pod, preventing access from or to an unauthorized endpoint.

For additional information on these topics, have a look at the Kubernetes documentation:

Kubernetes Services
Kubernetes Cluster Networking

You can also check out Play with Kubernetes, powered by Docker.
We will also be offering training on Kubernetes starting in early 2020. In the training, we’ll provide more specific examples and hands on exercises.To get notified when the training is available, sign up here:
Get Notified About Training

Designing Your First App in #Kubernetes, Part 3 — Communication via ServicesClick To Tweet

The post Designing Your First Application in Kubernetes, Part 3: Communicating via Services appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Designing Your First App in Kubernetes, Part 2: Setting up Processes

I reviewed the basic setup for building applications in Kubernetes in part 1 of this blog series. In this post, I’ll explain how to use pods and controllers to create scalable processes for managing your applications.
Processes as Pods & Controllers in Kubernetes
The heart of any application is its running processes, and in Kubernetes we fundamentally create processes as pods. Pods are a bit fancier than individual containers, in that they can schedule whole groups of containers, co-located on a single host, which brings us to our first decision point:
Decision #1: How should our processes be arranged into pods?
The original idea behind a pod was to emulate a logical host – not unlike a VM. The containers in a pod will always be scheduled on the same Kubernetes node, and they’ll be able to communicate with each other via localhost, making pods a good representation of clusters of processes that need to work together closely. 
A pod can contain one or more containers, but containers in the pod must scale together.
But there’s an important consideration: it’s not possible to scale individual containers in a pod separately from each other. If you need to scale your application up, you have to add more pods, which come with copies of every container they include. Factors such as which application components will scale at similar rates, which ones will not, and which ones should reside on the same host will factor into how you arrange processes in pods.
Thinking about our web app, we might start by making a pod containing only the frontend container; we want to be able to scale this frontend independently from the rest of our application, so it should live in its own pod.
On the other hand, we might design another pod that has one container each for our database and API; this way, our API is guaranteed to be able to talk to our database on the same physical host, eliminating network latency between the API and database and maximizing performance. As noted, this comes at the expense of independent scaling; if we schedule our API and database containers in the same pod, every time we want a new instance of our database container, it’s going to come with a new instance of our API.
Case specific arguments can be made for or against this choice: Is API-to-database latency really expected to be a major bottleneck? Could it be more important to scale your API and database separately? Final decisions may vary, but the same decision points can be applied generically to many applications.
Now that we have our pods planned out (one for the frontend and one for the API-plus-database combo), we need to decide how to manage these pods. We virtually never want to schedule pods directly (called ‘bare pods’); we want to take advantage of Kubernetes controllers, which will automatically reschedule failed pods, give us some simple influence on how and where our pods are scheduled, and give us some functionality on how to update and maintain those pods. There are at least two main types of controllers we need to decide between:
Decision #2: What kind of controller should we use for each pod: a deployment or a daemonset?

Deployments are the most common kind of controller, typically the best choice for stateless pods which can be scheduled anywhere resources are available.
DaemonSets are appropriate for pods meant to run one per host; these are typically used for daemon-like processes, like log aggregators, filesystem managers, system monitors or other utilities that make sense to have exactly one of on every host in your Kubernetes cluster.

Most, but not all, pods are best scheduled by one of these two controllers, and of them deployments make the large majority. Since neither of our web app components make sense as cluster-wide daemons, we would schedule both of them as deployments. If later we wanted to deploy a logging or monitoring appliance, a daemonSet would be a common pattern to ensure it runs on every node in the cluster.
Now that we’ve decided on how to arrange our containers into pods and how to manage our pods using controllers, its time to write some Kubernetes yaml to capture these objects; many examples of how to do this are available in the Kubernetes documentation and Docker’s Training material.
I strongly encourage you to define your applications using Kubernetes yaml definitions, and not imperative kubectl commands. As I mentioned in the first post, one of the most important aspects of orchestrating a containerized application is shareability, and it is much easier to share a yaml file you can check into version control and distribute, rather than a series of CLI commands that can quickly become hard to read and hard to keep track of.
Checkpoint #2: write Kubernetes yaml to describe your controllers and pods.
Once you have that yaml in hand, now’s a good time to create your deployments and make sure they all work as expected: individual containers in pods should run without crashing, and containers inside the same pod should be able to reach each other on localhost.
Advanced Topics
Once you’ve mastered the pods, deployments, and daemonSets mentioned above, there are a few deeper topics you can approach to enhance your Kube applications even further:

StatefulSets are another kind of controller appropriate for managing stateful pods; note these require an understanding of Kube services and storage (discussed below).
Scheduling affinity rules allow you to influence and control where your pods are scheduled in a cluster, useful for sophisticated operations in larger clusters.
Healthchecks in the form of livenessProbes are an important maintenance tool for your pods and containers, that tell Kube how to automatically monitor the health of your containers, and take action when they become unhealthy.
PodSecurityPolicy definitions allow an added layer of security for cluster administrators to control exactly who and how pods are scheduled, commonly used to prevent the creation of pods with elevated or root privileges.

To learn more about Kubernetes pods and controllers, read the documentation:

Kubernetes pods
Kubernetes controllers

You can also check out Play with Kubernetes, powered by Docker.
We will also be offering training on Kubernetes starting in early 2020. In the training, we’ll provide more specific examples and hands on exercises. To get notified when the training is available, sign up here:
Get Notified About Training

Designing Your First App in #Kubernetes, Part 2 — Processes as Pods and ControllersClick To Tweet

The post Designing Your First App in Kubernetes, Part 2: Setting up Processes appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Designing Your First App in Kubernetes, Part 1: Getting Started

Image credit: Evan Lovely

Kubernetes: Always Powerful, Occasionally Unwieldy
Kubernetes’s gravity as the container orchestrator of choice continues to grow, and for good reason: It has the broadest capabilities of any container orchestrator available today. But all that power comes with a price; jumping into the cockpit of a state-of-the-art jet puts a lot of power under you, but how to actually fly the thing is not obvious. 
Kubernetes’ complexity is overwhelming for a lot of people jumping in for the first time. In this blog series, I’m going to walk you through the basics of architecting an application for Kubernetes, with a tactical focus on the actual Kubernetes objects you’re going to need. I’m not, however, going to spend much time reviewing 12-factor design principles and microservice architecture; there are some excellent ideas in those sort of strategic discussions with which anyone designing an application should be familiar, but here on the Docker Training Team I like to keep the focus on concrete, hands-on-keyboard implementation as much as possible.
Furthermore, while my focus is on application architecture, I would strongly encourage devops engineers and developers building to Kubernetes to follow along, in addition to readers in application architecture roles. As container orchestration becomes mainstream, devops teams will need to anticipate the architectural patterns that application architects will need them to support, while developers need to be aware of the orchestrator features that directly affect application logic, especially around networking and configuration consumption. 
Just Enough Kube
When starting out with a machine as rich as Kubernetes, I like to identify the absolute minimum set of things we’ll need to understand in order to be successful; there’ll be time to learn about all the other bells and whistles another day, after we master the core ideas. No matter where your application runs, in Kubernetes or anywhere else, there are four concerns we are going to have to address:

 Processes: Your actual running code, compiled or interpreted, is the core of your application. We’re going to need a set of tools not only to schedule these processes, but to maintain and scale those processes over time. For this, we’re going to use pods and controllers.
 Networking: The processes that make up your application will likely need to talk to each other, external resources, and the outside world. We’re going to need tooling to allow us to do service discovery, load balancing and routing between all the components of our application. For this, we’re going to use Kubernetes services.
 Configuration: A well-written application factors out its configuration, rather than hard-coding it. This is a direct consequence of applying the paradigm of Don’t Repeat Yourself when coding; things that may change based on context, like access tokens, external resource locations, and environment variables should be defined in exactly one place which can be both read from and updated as needed. An orchestrator should be able to provision configuration in modular fashion, and for this we’re going to use volumes and configMaps.
 Storage: Well-built applications always assume their containers will be short lived, and that their filesystems will be destroyed with no warning. Any data collected or generated by a container, as well as any data that needs to be provisioned to a container, should be offloaded to some sort of external storage. For this, we’ll look at Container Storage Interface plugins and persistentVolumes.

And that’s it. I’ll provide some ‘advanced topics’ pointers throughout the blog series to give you some ideas on what to study after you’ve mastered the basics in order to take your Kubernetes apps even further. When you’re starting out, focus on the components mentioned above and detailed in this series.
Just Enough High-Level Design
I promised above to keep this series more tactical than strategic, but there are some high-level design points we absolutely need to understand the engineering decisions that follow, and to make sure we’re getting the maximum benefit out of our containerization platform. Regardless of what orchestrator we’re using, there are three key principles we need to keep in mind that set a standard for what we’re trying to achieve when containerizing applications: portability, scalability, and shareability:

 Portability: Whatever we build, we should be able to deploy it on any Kubernetes cluster; this means not having hard dependencies on any feature or configuration of the underlying host or its filesystem. If the idea of moving your app from your dev machine to a testing server sounds stressful, something probably needs to be rethought.
 Scalability: Containerized applications scale best when they scale horizontally: by adding more containers, and not just containers with more compute resources. It doesn’t matter how many resources are allocated to a container; they are still mortal and often short-lived objects managed by your orchestrator as it tries to adapt to changing cluster conditions and load. Therefore, we’re going to need to arrange our applications to easily leverage more copies of the containers it expects, typically by using the routing and load balancing features of our orchestrator, and by trying to make our containers stateless whenever possible.
 Shareability: We don’t want to be trapped maintaining and consulting on every app we build forever. It’s crucial that we’re able to share our apps with other developers who we may hand it off to in future, operators who have to manage it in production, and third parties who may be able to leverage it in an open-source context. We’re halfway there with portability, ensuring that it’s possible to move our app from cluster to cluster, but beyond it just being technically possible, shareability emphasizes that hand off should also be easy and reliable. Standing up our app on a new cluster should be as foolproof as possible, at least for a first pass.

Thinking Through Your First Application on Kubernetes
For the rest of this series, let’s think through containerizing a simple three-tier web app for Kubernetes, with the following typical components:

 A database for holding all the data required by the application
 An API which is allowed to access the database
 A frontend which is reachable by users on the web, and which uses the API to interact with the database

Even if applications like these are the furthest thing from what you work with, the example is instructive; we’ll focus on decision points that are widely applicable to many different kinds of applications, so you can see examples of how to make these decisions. The generic application above is just a vehicle for touring the relevant concepts, but they apply quite generally.
Let’s begin by imagining that you’ve already created Docker images for each component of your application, whether they resemble the components listed above or are completely different. If you’d like a primer on designing and building Docker images, see my colleague Tibor Vass’s excellent blog post on dockerfile best practices.
Checkpoint #1: Make your images.
Before you’ll be able to orchestrate anything, you’ll need images built for every type of container you want to run in your application.
Also note, we’re going to consider some of the simplest cases for each concern; start with these, and when you master them, see the Advanced Topics subsection in each step for pointers to what topics to explore next.
You’ve made it this far! In the next post, I’ll explore setting up processes as pods and controllers.
We will also be offering training on Kubernetes starting in early 2020. To get notified when the training is available, sign up here:
Get Notified About Training
To learn more about running Kubernetes with Docker:

Try the Docker Kubernetes Service, the easiest way to securely run and manage Kubernetes in the enterprise.
Try out Play with Kubernetes.
Find out how to simplify Kubernetes with Docker Compose.

Getting Started: How To Build Your First Application in #Kubernetes (part 1)Click To Tweet

The post Designing Your First App in Kubernetes, Part 1: Getting Started appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Docker + Arm Virtual Meetup Recap: Building Multi-arch Apps with Buildx

Docker support for cross-platform applications is better than ever. At this month’s Docker Virtual Meetup, we featured Docker Architect Elton Stoneman showing how to build and run truly cross-platform apps using Docker’s buildx functionality. 
With Docker Desktop, you can now describe all the compilation and packaging steps for your app in a single Dockerfile, and use it to build an image that will run on Linux, Windows, Intel and Arm – 32-bit and 64-bit. In the video, Elton covers the Docker runtime and its understanding of OS and CPU architecture, together with the concept of multi-architecture images and manifests.
The key takeaways from the meetup on using buildx:

Everything should be multi-platform
Always use multi-stage Dockerfiles 
buildx is experimental but solid (based on BuildKit)
Alternatively use docker manifest — also experimental

Not a Docker Desktop user? Jason Andrews, a Solutions Director at Arm, posted this great article on how to setup buildx using Docker Community Engine on Linux. 
Check out the full meetup on Docker’s YouTube Channel:

You can also access the demo repo here. The sample code for this meetup is from Elton’s latest book, Learn Docker in a Month of Lunches, an accessible task-focused guide to Docker on Linux, Windows, or Mac systems. In it, you’ll learn practical Docker skills to help you tackle the challenges of modern IT, from cloud migration and microservices to handling legacy systems. There’s no excessive theory or niche-use cases — just a quick-and-easy guide to the essentials of Docker you’ll use every day (use the code webdoc40 for 40% off).
To get started building multi-arch apps today:

Download Docker Desktop 
Read about Building Multi-Arch Images for Arm and x86 with Docker Desktop
Watch the DockerCon session on Developing Containers for Arm

#Docker + @arm virtual meetup recap: How to build multi-arch images with buildxClick To Tweet

The post Docker + Arm Virtual Meetup Recap: Building Multi-arch Apps with Buildx appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

New in Docker Hub: Personal Access Tokens

The Hub token list view.
On the heels of our recent update on image tag details, the Docker Hub team is excited to share the availability of personal access tokens (PATs) as an alternative way to authenticate into Docker Hub.
Already available as part of Docker Trusted Registry, personal access tokens can now be used as a substitute for your password in Docker Hub, especially for integrating your Hub account with other tools. You’ll be able to leverage these tokens for authenticating your Hub account from the Docker CLI – either from Docker Desktop or Docker Engine: 
docker login –username <username>
When you’re prompted for a password, enter your token instead.
The advantage of using tokens is the ability to create and manage multiple tokens at once so you can generate different tokens for each integration – and revoke them independently at any time.
Create and Manage Personal Access Tokens in Docker Hub 
Personal access tokens are created and managed in your Account Settings.
From here, you can:

Create new access tokens
Modify existing tokens
Delete access tokens

Creating an access token in Docker Hub.
Note that the actual token is only shown once, at the time of creation. You will need to copy the token and save it in either a credential manager or use it immediately. If you lose a token, you will need to delete the lost token and create a new one. 
The Next Step for Tokens
Personal access tokens open a new set of ways to authenticate into your Docker Hub account. Their introduction also serves as a foundational building block for more advanced access control capabilities, including multi-factor authentication and team-based access controls – both areas that we’re working on at the moment. We’re excited to share this and many other updates that are coming to Docker Hub over the next few months. Give access tokens a try and let us know what you think!
To learn more about personal access tokens for Docker Hub:

Read more about Docker Hub
Explore the Docker Hub documentation 
Get started with Docker by creating your Hub account

New in #DockerHub: Personal Access TokensClick To Tweet

The post New in Docker Hub: Personal Access Tokens appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

How Wiley Education Services Empowers Students with Docker Enterprise

We sat down recently with our customer, Wiley Education Services, to find out how Docker Enterprise helps them connect with and empower higher education students. Wiley Education Services (WES) is a division of Wiley Publishing that delivers online services to over 60 higher education institutions.
We spoke with Blaine Helmick, Senior Manager of Systems Engineering about innovation and technology in education. Read on to learn more about Wiley, or watch the short video interview with Blaine:

On Wiley’s Mission…
Our mission at Wiley Education Services is empowering people, to connect people to their futures. We serve over 60 higher education partners around the world, and our role is to connect you to our higher education partners when you’re looking for a degree and you’re frankly looking to change your life. 
On the Innovation at a 200 Year Old Company… 
Wiley has been around for over 200 years. One of the really amazing things about being in an organization that’s been around that long is that you have to have a culture of innovation at your core. 
Technology like Docker has really empowered our business because it allows us to innovate, and it allows us to experiment. That’s critical because experimentation and being allowed to fail is what allows us to innovate and learn. 
An Architecture that Wouldn’t Scale…
Our business first looked at Docker right about when I joined in late 2016. Our marketing solution for higher education partners was running on two VMs in AWS, including the database, and it just wasn’t scalable. We just didn’t have the ability that we needed to quickly adapt and evolve to meet the needs of our higher education partners. If we wanted to stay competitive we were going to have to make some architectural changes. 
And a Memorable Outage…
A memorable experience at Wiley for me was when we had a huge outage on the servers that ran our core service. We were down for a good three days while we essentially rebuilt our infrastructure. It led to an epiphany about the analysis we had done of our infrastructure. Our partner had already recommended Docker, but it hadn’t coalesced yet. That was the moment it did. 
On How Docker Helps Wiley Achieve Their Vision
Docker helps us make good on the mission at Wiley by reducing the amount of time that it takes for us to get one of our websites out in the marketplace to help and empower students. If we can make the connection to students faster and deliver new information that helps connect those students to our higher education partners, that’s incredibly important. Closing that gap is what empowers us and ultimately empowers those students to succeed.
On Innovation without the Cost…
Docker has been eye-opening for me. One key benefit that we got immediately with Docker Enterprise was speed — how quickly we can create and publish containers, test them, and bring them back down if they don’t work without the long cycles we needed before. That’s huge, because it lets us innovate quickly.
The second thing that it brought us was cost savings. The ability to bring up new tech rapidly without necessarily having to make huge investments has been tremendous. 
The Future at Wiley Education Services
Now we’re looking to bring Docker throughout the organization so that we’re not just taking what we have and putting it out into docker containers, but also introducing things like microservices, or being able to take multiple datacenters from around the world and orchestrate our containers so we have full redundancy.
But it isn’t just about redundancy. It’s about meeting our students — and customers — where they are. So having the capability that Docker and Kubernetes provides will let us take our marketing sites and move them throughout the world so we’re reaching students where they are. That’s what allows us to reach those students faster. 
To learn more about Wiley’s story and how Docker can help you innovate:

Watch Wiley’s DockerCon presentation
Read the Digital Transformation Imperative eBook

@blainehelmick explains how @WileyEdServices empowers students at over 60 colleges and universities with #Docker EnterpriseClick To Tweet

The post How Wiley Education Services Empowers Students with Docker Enterprise appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

How InterSystems Builds an Enterprise Database at Scale with Docker Enterprise

We sat down recently with InterSystems, our partner and customer, to talk about how they deliver an enterprise database at scale to their customers. InterSystems’s software powers mission-critical applications at hospitals, banks, government agencies and other organizations.
We spoke with Joe Carroll, Product Specialist, and Todd Winey, Director of Partner Programs at InterSystems about how containerization and Docker are helping transform their business.
Here’s what they told us. You can also catch the highlights in this 2 minute video:

On InterSystems and Enterprise Databases…
Joe Carroll: InterSystems is a 41 year old database and data platform company. We’ve been in data storage for a very long time and our customers tend to be traditional enterprises — healthcare, finance, shipping and logistics as well as government agencies. Anywhere that there’s mission critical data we tend to be around. Our customers have really important systems that impact people’s lives, and the mission critical nature of that data characterizes who our customers are and who we are.
On Digital Transformation in Established Industries…
Todd Winey: Many of those organizations and industries have been traditionally seen as laggards in terms of their technology adoption in the past, so the speed with which they’re moving to digital transformation is a key theme for everyone involved. Our customers are really seeing the benefits of being able to adopt technology faster and with a higher degree of confidence.
Our goal is to support them on that journey with our software. To do that, we’ve had to transform our business at InterSystems.
Why Docker…
Todd: From a software delivery standpoint, Docker has provided some truly amazing capabilities. Quality development was probably one of the biggest bottlenecks we faced, along with creating the processes we needed to ensure good quality software was going out the door.
And so rather than solve it by trying to throw more people at the problem, Docker’s platform allows us to do a lot of automation in that process so that we’re getting orders of magnitude improvements without additional staff.
On Scaling Software Testing for an Enterprise Database…
Joe: The InterSystems IRIS platform is the latest iteration of our database platform, and is built container and cloud first. We modernized the database with Docker Enterprise is our database software. 
The scalability the Docker Enterprise gives us in terms of our testing infrastructure allows us to go from what was before a tens of tests a day to thousands of tests every night, to eventually tens of thousands of tests every night. We’re able to provide higher quality of software four our customers because of this testing infrastructure. 
We’re able to test at scale, and do that quickly without sacrificing quality. And when we kick off our testing suite we can be confident the software will run on whatever cloud provider we need, so we can ensure portability of our application. 
On How Docker has Helped…
Todd: Adopting Docker Enterprise really provided three key benefits. We’re getting quarterly releases out the door whereas before we’re we’re looking at maybe one major release, and really starting to push the envelope on continuous delivery. So our customers who are ready to take software with a new build on a daily basis, we can meet those demands.
Staffing of the software quality development process is much easier. We’re able to do more with less, which is what every business wants and what every business wants out a digital transformation.
We’ve always delivered our software across a large number of operating systems. Docker allows us to treat cloud as one more operating system, so we can provide flexibility to our customers to run our software confidently where they want.
The Future for InterSystems
InterSystems expects to continue improving its software release cycle, delivering software updates daily to its enterprise database.
To learn more about InterSystems and how Docker helps enterprises build better software:

Watch the InterSystems DockerCon 2019 session
See what’s new in Docker Enterprise 3.0

How @InterSystems builds their enterprise database software at scale with Docker EnterpriseClick To Tweet

The post How InterSystems Builds an Enterprise Database at Scale with Docker Enterprise appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Powering Docker App: Next Steps for Cloud Native Application Bundles (CNAB)

Last year at DockerCon and Microsoft Connect, we announced the Cloud Native Application Bundle (CNAB) specification in partnership with Microsoft, HashiCorp, and Bitnami. Since then the CNAB community has grown to include Pivotal, Intel, DataDog, and others, and we are all happy to announce that the CNAB core specification has reached 1.0.
We are also announcing the formation of the CNAB project under the Joint Development Foundation, a part of the Linux Foundation that’s chartered with driving adoption of open source and standards. The CNAB specification is available at cnab.io. Docker is working hard with our partners and friends in the open source community to improve software development and operations for everyone.
Docker’s Implementation of CNAB — Docker App
Docker was one of the first to implement the CNAB specification with Docker App, our reference implementation available on GitHub. Docker App can be used to both build CNAB bundles for Docker Compose (which can then be used with any other CNAB client), and also to install, upgrade, and uninstall any other CNAB bundle.
It also forms the underpinnings of application templates in Docker Desktop Enterprise. With Docker App, we are making CNAB-compliant applications as easy to use as Docker images; you will get the same benefits of immutability and a simple user experience for building, sharing and running containers now applied to multi-service applications. 
Docker’s contribution to CNAB stems from our desire to build an application ecosystem like we did for the container ecosystem. And CNAB is the building block for this — it’s a packaging format. Going forward, Docker recognizes that a single container is not enough to express an application. This is why Docker’s strategy is to help grow this application ecosystem and make modern applications a core part of our platform. This means building, managing, and securing all of your applications from traditional applications to cutting-edge microservices — and deploying them anywhere.
What Comes Next
Docker is excited to see the momentum building with CNAB from our new partners, Pivotal, DataDog, and Intel as well as Microsoft, Bitnami, and HashiCorp who started the journey with us. There is sill a lot more to do, including ensuring that both Docker App – our reference implementation of the spec – and all other CNAB tools become core 1.0 compliant. We will also continue to provide community leadership and help drive further industry adoption of CNAB. Stay tuned for more exciting announcements from Docker and the CNAB community.

Powering Docker App: Next Steps for #Cloud Native Application Bundles (CNAB)Click To Tweet

Getting Started
Docker welcomes you to get involved with the community. Here are some resources to get started:

CNAB explainer video presented by Docker and Microsoft. 
CNAB 1.0 Core Specification
Join the #cnab channel in the CNCF’s Slack. The CNAB community has an open meeting every other Wednesday at 09:00AM US Pacific.
Video from DockerCon19: Deploying Distributed Applications with Docker App and CNAB
Docker App: Make your Docker Compose applications reusable, and share them on Docker Hub 
Deis Labs has a blog series on CNAB: Part 1, and Part 2.

The post Powering Docker App: Next Steps for Cloud Native Application Bundles (CNAB) appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Introducing Docker Hub’s New & Improved Tag User Experience

One of Docker’s core missions is delivering choice and flexibility across different application languages and frameworks, operating systems, and infrastructure. When it comes to modern applications, the choice of infrastructure is not just whether the application is run on-premises, on virtual machines or bare metal, or in the cloud. It can also be a choice of which architecture – x86, Arm, or GPU. 
Today, we’re happy to share some updates in Docker Hub that make it easier to access multi-architecture images and scanning results through the Tag UX. 
Navigating to Image Tags
In this example, we’re looking at a listing for a Docker Official Image that supports x86, PowerPC and IBMz as listed in the labels. When you land on the image page on Docker Hub, you can quickly identify if an image supports multiple architectures in the labels underneath the image name. For further details, you can click on ‘Tags’:

In this section, you can now view the different architectures separately to easily identify the right image for the architecture you need, complete with image size and operating system information:

If you click on the digest for a particular architecture, you will now also be able to see the actual source of the image – the layer-by-layer details that make up the image. 
If vulnerability scanning was completed on that image, you’ll also be able to quickly identify if the image has any known vulnerabilities and if there are, whether these vulnerabilities are rated as critical, major or minor. The scanning results are based on a binary level scan of the image against the CVE database. 
In this second example, you’ll see that layers 2 to 6 have passed vulnerability scanning via the green checkboxes, but the very first layer of the image has issues:

When you click on the first row, you’ll see that the image contains multiple components and that multiple components have known vulnerabilities ranging from minor to critical. To explore further, click on the caret to expand and view all of the found vulnerabilities:

Each vulnerability is linked directly to the CVE so that you can learn more about the CVE and its implications. That will allow you to decide if it needs to be fixed or not. 
Get Started with Docker and Explore Docker Hub
Docker Hub is a great place to start learning more about Docker containers. Create your own account and get access to a guided tutorial on using Docker Hub and the free Docker Desktop. With your account, you also get free public repositories and one free private repository to start sharing and collaborating on content.

New in #DockerHub – Improved Tag User Experience, Including Multi-Architecture DetailClick To Tweet

Create a Docker Hub Account
To learn more about Docker Hub:

Create your Docker Account
Read the Docker Hub Quickstart
Find out how to integrate Docker Hub and Docker Trusted Registry

The post Introducing Docker Hub’s New & Improved Tag User Experience appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/