Kubernetes News, Entwicklungen, Updates, HowTos - Seite 140 von 184

Regal Princess cruise ship. Photo by Jamie Morrison on Unsplash
When you get on a cruise ship or go to a major resort, there’s a lot happening behind the scenes. Thousands of people work to create amazing, memorable experiences, often out of sight. And increasingly, technology helps them make those experiences even better.
We sat down recently with Todd Heard, VP of Infrastructure at Carnival Corporation, to find out how technology like Docker helps them create memorable experiences for their guests. Todd and some of his colleagues worked at Disney in the past, so they know a thing or two about memorable experiences.
Here’s what he told us. You can also catch the highlights in this 2 minute video:

On Carnival’s Mission
Our goal at Carnival Corporation is to provide a very personalized, seamless, and customized experience for each and every guest on their vacation. Our people and technology investments are what make that possible. But we also need to keep up with changes in the industry and people’s lifestyles.
On Technology in the Travel Industry and Customized Guest Experiences
One of the ironies in the travel industry is that everybody talks about technology, but the technology should be invisible to the guest. Travel industry players use technology to differentiate their capabilities and products and services, but essentially guests want more engagement with their travel provider. Technology helps us build and customize memorable experiences for each guest, but the technology itself isn’t the experience.
In the travel and hospitality industry, digital transformation is all about the guest experience. And now you’ll see more companies investing in more innovation that drive more personalized interactions and experiences for the guests. For us at Carnival, digital transformation means that the more that a guest interacts and participates in a particular brand or experience, the more personalized it becomes because it’s always adapting and adjusting and anticipating those guests needs.
Carnival Corporation’s MedallionClass Experience
We are rolling out the MedallionClass experience which is powered by a wearable OceanMedallion that gives the guests more ways to engage with us and receive personalized service on demand at any time on the ship.
For example, traditionally you think on a cruise ship if you’re sitting by the swimming pool you have people walking by you and you can order a drink. But what if you’re somewhere else? Perhaps you’re sharing an intimate moment with someone at the back of the ship and you want to order a bottle of champagne. The Medallion allows the crew to find your location and deliver it to you.
We also have gamification built into the platform, “find your shipmates,” room entry and dozens of other services tied to MedallionClass. All of that allows us to provide very personalized interactions with our guests.
The Technology Behind MedallionClass
The MedallionClass program is based on a micro strategy architecture with over 300 services deployed. All of these services work together to create very distinct experiences for our guests. Each ship has about 120 containers running across two shipboard data centers. That gives us high availability in a very small footprint to make sure our guest services are always available.
As part of MedallionClass, we use a hybrid cloud based architecture where we use Docker Enterprise in all of our lower environments and also deploy it on the ships to run our services that provide these experiences for our guests.
How Docker Makes MedallionClass Possible
Docker plays a very critical role in our digital transformation with the MedallionClass. Cruise ships are essentially mobile cities that provide everything that a guest could need or want, including food and beverage, recreation, accommodations, transportation, telecommunications, gaming and more. And what Docker gives us is the unique ability to control the entire guest experience by connecting all these elements together.
Docker lets us be very agile so our developers are more productive. As we develop and create highly innovative new personalized guest experiences we can get those to market quickly for our guests.
Docker Enterprise has also allowed us to reduce our overall infrastructure footprint on the ship, and it helps drive standardization as we continue to rollout MedallionClass experiences to our fleet of ships.
To learn more about how Docker Enterprise can help you create memorable customer experiences:

Read the Digital Transformation Imperative eBook
Download the Definitive Guide to Container Platforms

How @CarnivalPLC creates customized guest experiences and uses #Docker Enterprise to power @medallionclassClick To Tweet

The post How Carnival Corporation Creates Customized Guest Experiences with Docker Enterprise appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

2. Oktober 2019

da Agency

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.

You can continue reading about Kubernetes application configuration in part 4.
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/

1. Oktober 2019

da Agency

At the Grace Hopper Celebration, Learn Why Developers Love Docker

Lisa Dethmers-Pope and Amn Rahman at Docker also contributed to this blog post.
Docker hosted a Women’s Summit at DockerCon 2019.
As a Technical Recruiter at Docker, I am excited to be a part of Grace Hopper Celebration. It is a marvelous opportunity to speak with many talented women in tech and to continue pursuing one of Docker’s most valued ambitions: further diversifying our team. The Docker team will be on the show floor at the Grace Hopper Celebration, the world’s largest gathering of women technologists the week of October 1st in Orlando, Florida.
Our Vice President of Human Resources, and our Senior Director of Product Management, along with representatives from our Talent Acquisition and Engineering teams will be there to connect with attendees. We will be showing how to easily build, run, and share an applications using the Docker platform, and talking about what it’s like to work in tech today.
Supporting Women in Tech
While we’ve made strides in diversity within tech, the 2019 Stack Overflow Developer Survey shows we have work to do. According to the survey, only 7.5 percent of professional developers are women worldwide (it’s 11 percent of all developers in the U.S.).
That’s why Docker hosts Women in Tech events at our own conferences, and we’re pleased to participate in the Grace Hopper Celebration this year. It’s a place for women technologists to learn, network, and connect with a like-minded community. The conference offers attendees several opportunities to advance their professional development, find and provide mentorship, and further develop their leadership skills.
Last year’s celebration hosted over 20,000 attendees from 78 countries as well as thousands of listeners over livestream. We are thrilled to be involved with the conference and show our support for an organization making such a powerful impact.
Creating and Fostering Connections
2 million developers already use Docker regularly today. We have over 240 regional user groups, and a presence in 80 countries. Diversity and inclusion are a key part of our community, and we’ll continue building on that as we grow.
We are seeking forward-thinking individuals to join our team who have diverse experiences and are passionate about bringing technology that transforms lives, industries, and the world to life.
Whether you’re a curious explorer, a Docker newbie, or a super-powered Docker ninja, you should come join us at the Docker booth to learn more about how you can get the most benefit out of the platform!
If you’re a data scientist, a developer, or just bouncing from one coding assignment to the next, come and learn how you can start using Docker almost immediately! Apart from being introduced to cool Docker lingo, you’ll learn how to quickly launch a Docker environment, spin up an app on your machine, and share it with the rest of the world via Docker Hub.
We look forward to collaborating and connecting with you. Come visit us at the technology showcase booth 359, 3648!
In the meantime, if you’d like to dive into diversity in tech, these three DockerCon sessions are a great starting point:

A Transformation of Attitude: Why Mentor Matter
Diversity is not Only about Ethnicity and Gender
How Intentional Diversity Creates Thought Leadership

At @ghc, learn why #developers love Docker and why #diversity in the developer community matters to usClick To Tweet

The post At the Grace Hopper Celebration, Learn Why Developers Love Docker appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

1. Oktober 2019

da Agency

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.

From here, we wrap up the series with a post about storage configuration for Kubernetes applications.
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/

1. Oktober 2019

da Agency

Designing Your First Application in Kubernetes, Part 5: Provisioning Storage

In this blog series on Kubernetes, we’ve already covered:

The basic setup for building applications in Kubernetes
How to set up processes using pods and controllers
Configuring Kubernetes networking services to allow pods to communicate reliably
How to identify and manage the environment-specific configurations to make applications portable between environments

In this series’ final installment, I’ll explain how to provision storage to a Kubernetes application.

Step 4: Provisioning Storage
The final component we want to think about when we build applications for Kubernetes is storage. Remember, a container’s filesystem is transient, and any data kept there is at risk of being deleted along with your container if that container ever exits or is rescheduled. If we want to guarantee that data lives beyond the short lifecycle of a container, we must write it out to external storage.
Any container that generates or collects valuable data should be pushing that data out to stable external storage. In our web app example, the database tier should be pushing its on-disk contents out to external storage so they can survive a catastrophic failure of our database pods.
Similarly, any container that requires the provisioning of a lot of data should be getting that data from an external storage location. We can even leverage external storage to push stateful information out of our containers, making them stateless and therefore easier to schedule and route to.
Decision #5: What data does your application gather or use that should live longer than the lifecycle of a pod?
The full Kubernetes storage model has a number of moving parts:
The Kubernetes storage model.

Container Storage Interface (CSI) Plugins can be thought of as the driver for your external storage.
StorageClass objects take a CSI driver and add some metadata that typically configures how storage on that backend will be treated
PersistentVolume (PV) objects represent an actual bucket of storage, as parameterized by a StorageClass
PersistentVolumeClaim (PVC) objects allow a pod to ask for a PersistentVolume to be provisioned to it
Finally, we met Volumes earlier in this series. In the case of storage, we can populate a volume with the contents of the external storage captured by a PV and requested by a PVC, provision that volume to a pod and finally mount its contents into a container in that pod.

Managing all these components can be cumbersome during development, but as in our discussion of configuration, Kubernetes volumes provide a convenient abstraction by defining how and where to mount external storage into your containers. They form the start of what I like to think of as the “storage frontend” in Kubernetes—these are the components most closely integrated with your pods and which won’t change from environment to environment.
All those other components, from the CSI driver all the way through the PVC, which I like to think of as the “storage backend”, can be torn out and replaced as you move between environments without affecting your code, containers, or the controller definitions that deploy them.
Note that on a single-node cluster (like the one created for your by Docker Desktop on your development machine), you can create hostpath backed persistentVolumes which will provision persistent storage from your local disk without setting up any CSI plugins or special storage classes. This is an easy way to get started developing your application without getting bogged down in the diagram above—effectively deferring the decision and setup of CSI plugins and storageClasses until you’re ready to move off of your dev machine and into a larger cluster.
Advanced Topics
The simple hostpath PVs mentioned above are appropriate for early development and proof-of-principle work, but they will need to be replaced with more powerful storage solutions before you get to production. This will require you to look into the ‘backend’ components of Kubernetes’ storage solution, namely StorageClasses and CSI plugins:

StorageClasses
Container Storage Interface plugins

The Future
In this series, I’ve walked you through the basic Kubernetes tooling you’ll need to containerize a wide variety of applications, and provided you with next-step pointers on where to look for more advanced information. Try working through the stages of containerizing workloads, networking them together, modularizing their config, and provisioning them with storage to get fluent with the ideas above.
Kubernetes provides powerful solutions for all four of these areas, and a well-built app will leverage all four of them. If you’d like more guidance and technical details on how to operationalize these ideas, you can explore the Docker Training team’s workshop offerings, and check back for new Training content landing regularly.
After mastering the basics of building a Kubernetes application, ask yourself, “How well does this application fit the values of portability, scalability and shareability we started with?” Containers themselves are engineered to easily move between clusters and users, but what about the entire application you just built? How can we move that around while still preserving its integrity and not invalidating any unit and integration testing you’ll perform on it?
Docker App sets out to solve that problem by packaging applications in an integrated bundle that can be moved around as easily as a single image. Stay tuned to this blog and Docker Training for more guidance on how to use this emerging format to share your Kubernetes applications seamlessly.
To learn more about Kubernetes storage and Kubernetes in general:

Read the Kubernetes documentation on PersistentVolumes and PersistentVolumeClaims.
Find out more about running Kubernetes on Docker Enterprise and Docker Desktop.
Check out Play with Kubernetes, powered by Docker.

Designing Your First App in #Kubernetes, Part 5 — Provisioning StorageClick To Tweet

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

1. Oktober 2019

da Agency

Building Your First Certified Kubernetes Cluster On-Premises, Part 1

This is the first in a series of guest blog posts by Docker Captain Ajeet Raina diving in to how to run Kubernetes on Docker Enterprise. You can follow Ajeet on Twitter @ajeetsraina and read his blog at http://www.collabnix.com.

There are now a number of options for running certified Kubernetes in the cloud. But let’s say you’re looking to adopt and operationalize Kubernetes for production workloads on-premises. What then? For an on-premises certified Kubernetes distribution, you need an enterprise container platform that allows you to leverage your existing team and processes.
Enter Docker Kubernetes Service
At DockerCon 2019, Docker announced the Docker Kubernetes Service (DKS). It is a certified Kubernetes distribution that is included with Docker Enterprise 3.0 and is designed to solve this fundamental challenge.
In this blog series, I’ll explain Kubernetes support and capabilities under Docker Enterprise 3.0, covering these topics:

Deploying certified Kubernetes Cluster using Docker Enterprise 3.0 running on a Bare Metal System
Implementing Persistent storage for Kubernetes workload using iSCSI
Implementing Cluster Ingress for Kubernetes
Deploying Istio Service Mesh under Docker Enterprise 3.0
Support of Kubernetes on Windows Server 2019 with Docker Enterprise 3.0

So About DKS…
DKS is the only offering that integrates Kubernetes from the developer desktop to production servers, with ‘sensible secure defaults’ out-of-the-box. Simply put, DKS makes Kubernetes easy to use and more secure for the entire organization. Here are three things that DKS does to simplify and accelerate Kubernetes adoption for the enterprise:

Consistent, seamless Kubernetes experience for developers and operators. With the use of Version Packs, developers’ Kubernetes environments running in Docker Desktop Enterprise stay in sync with production environments for a complete, seamless Kubernetes experience.
Streamlined Kubernetes lifecycle management (Day 1 and Day 2 operations). A new Cluster Management CLI Plugin allows operations teams to easily deploy, scale, backup and restore and upgrade a certified Kubernetes environment using a set of simple CLI commands.
Enhanced security with ‘sensible defaults.’ Teams get out-of-the-box configurations for security, encryption, access control, and lifecycle management — all without having to become Kubernetes experts.

DKS is compatible with Kubernetes YAML, Helm charts, and the Docker Compose tool for creating multi-container applications. It also provides an automated way to install and configure Kubernetes applications across hybrid and multi-cloud deployments. Capabilities include security, access control, and lifecycle management. Additionally, it uses Docker Swarm Mode to orchestrate Docker containers.
Kubernetes 1.14+ in Docker Enterprise
Docker Enterprise 3.0 comes with the following components:

Containerd 1.2.6
Docker Engine 19.03.1
Runc 1.0.0-rc8
docker-init 0.18.0
Universal Control Plane 3.2.0
Docker Trusted Registry 2.7
Kubernetes 1.14+
Calico v3.5.7

Docker UCP manager and worker nodes.
In this first post of the series, I will show you how to deploy a Certified Kubernetes cluster using Docker Enterprise 3.0 on bare metal (meaning you can deploy on-premises).
Pre-Requisites:

Ubuntu 18.04 (at least 2 Node to setup Multi-Node Cluster)
Minimal 4GB RAM is required for UCP 3.2.0
Go to https://hub.docker.com/my-content.
Click the Setup button for Docker Enterprise Edition for Ubuntu.
Copy the URL from the field labeled Copy and paste this URL to download your Edition.

Now you’re ready to start installing Docker Enterprise and Kubernetes. Let’s get started.
Step 1: Install packages to allow apt to use a repository over HTTPS
$sudo apt-get install
apt-transport-https
ca-certificates
curl
software-properties-common
Step 2: Add the $DOCKER_EE_URL variable into your environment
Replace with the URL you noted down in the prerequisites. Replace sub-xxx too.
$curl -fsSL https://storebits.docker.com/ee/m/sub-XXX-44fb-XXX-b6bf-XXXXXX/ubuntu/gpg |
sudo apt-key add –
Step 3: Add the stable Repository
$sudo add-apt-repository
“deb [arch=amd64] https://storebits.docker.com/ee/m/sub-XXX-44fb-XXX-b6bf-XXXXXX/ubuntu
$(lsb_release -cs)
stable-19.03″
Step 4: Install Docker Enterprise
$sudo apt-get install docker-ee docker-ee-cli containerd.io
Step 5: Verifying Docker Enterprise Version
$ sudo docker version
Client: Docker Engine – Enterprise
Version: 19.03.1
API version: 1.40
Go version: go1.12.5
Git commit: f660560
Built: Thu Jul 25 20:59:23 2019
OS/Arch: linux/amd64
Experimental: false

Server: Docker Engine – Enterprise
Engine:
Version: 19.03.1
API version: 1.40 (minimum version 1.12)
Go version: go1.12.5
Git commit: f660560
Built: Thu Jul 25 20:57:45 2019
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.2.6
GitCommit: 894b81a4b802e4eb2a91d1ce216b8817763c29fb
runc:
Version: 1.0.0-rc8
GitCommit: 425e105d5a03fabd737a126ad93d62a9eeede87f
docker-init:
Version: 0.18.0
GitCommit: fec3683
cse@ubuntu1804-1:~$
Step 6: Test the Hello World Example
$ sudo docker run hello-world
Unable to find image ‘hello-world:latest’ locally
latest: Pulling from library/hello-world
1b930d010525: Pull complete
Digest: sha256:6540fc08ee6e6b7b63468dc3317e3303aae178cb8a45ed3123180328bcc1d20f
Status: Downloaded newer image for hello-world:latest

Hello from Docker!

This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the “hello-world” image from the Docker Hub.
(amd64)
3. The Docker daemon created a new container from that image which runs the executable
that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it to your
terminal.
To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash
Share images, automate workflows, and more with a free Docker ID by signing up or logging in to Docker Hub.
For more examples and ideas, visit the Docker Docs getting started page.
Step 7: Install Universal Control Plane v3.2.0
$ sudo docker container run –rm -it –name ucp
> -v /var/run/docker.sock:/var/run/docker.sock
> docker/ucp:3.2.0 install
> –host-address 10.94.214.115
> –interactive
Step 8: Accessing the UCP
Now you should be able to access Docker Universal Control Plane via https://<node-ip>

Click on “Sign In” and upload the license file to access Docker Enterprise UCP 3.2.0 WebUI as shown below:

Step 9: Adding Worker Nodes to the Cluster
Let’s add worker nodes to the cluster. Click on “Shared Resources” on the left pane and Click on “Nodes”. Select “Add Nodes” and choose an orchestrator. You can also add either Linux or Windows nodes to the cluster here as shown below:

I assume that you have a worker node installed with Ubuntu 18.04 and the latest Docker binaries (it can be either the free version of Docker Engine or Docker Enterprise).
@ubuntu1804-1:~$ sudo curl -sSL https://get.docker.com/ | sh

$ sudo usermod -aG docker cs
$ sudo docker swarm join –token SWMTKN-1-3n4mwkzhXXXXXXt2hip0wonqagmjtos-bch9ezkt5kiroz6jncid
rz13x <managernodeip>:2377
This node joined a swarm as a worker.
By now, you should be able to see both manager node and 1 worker node added under UCP.

If you see a warning on the UCP dashboard stating that you have a similar hostname on both the manager and worker node, change the hostname on the worker node and it will automatically get updated on UCP dashboard.
Step 10: Install the Docker Client Bundle
Click on Dashboard and scroll down to see the Docker CLI option. This option allows you to download a client bundle to create and manage services using the Docker CLI client. Once you click, you will be able to find a new window as shown below:

Click on “user profile page” and it should redirect you to https://<manager-ip-node/manage/profile/clientbundle page as seen in the below screenshot:

Click on “Generate Client Bundle” and it will download ucp-bundle-<username>.zip
$ unzip ucp-bundle-ajeetraina.zip
Archive: ucp-bundle-ajeetraina.zip
extracting: ca.pem
extracting: cert.pem
extracting: key.pem
extracting: cert.pub
extracting: kube.yml
extracting: env.sh
extracting: env.ps1
extracting: env.cmd
extracting: meta.json
extracting: tls/docker/key.pem
extracting: tls/kubernetes/ca.pem
extracting: tls/kubernetes/cert.pem
extracting: tls/kubernetes/key.pem
extracting: tls/docker/ca.pem
extracting: tls/docker/cert.pem
@ubuntu1804-1:~$ eval “$(<env.sh)”
The env script updates the DOCKER_HOST and DOCKER_CERT_PATH environment variables to make the Docker CLI client interact with UCP and use the client certificates you downloaded. From now on, when you use the Docker CLI client, it includes your user specific client certificates as part of the request to UCP.
Step 11: Install Kubectl on Docker Enterprise 3.0
Once you have the Kubernetes version, install the kubectl client for the relevant operating system. As shown below, we need to install Kubectl version 1.14.3:

Step 12: Set the Kubectl version
@ubuntu1804-1:~$ k8sversion=v1.14.3
@ubuntu1804-1:~$ curl -LO https://storage.googleapis.com/kubernetes-release/release/
$k8sversion/bin/linux/amd64/kubectl
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 41.1M 100 41.1M 0 0 7494k 0 0:00:05 0:00:05 –:–:– 9070k
@ubuntu1804-1:~$ chmod +x ./kubectl
@ubuntu1804-1:~$ sudo mv ./kubectl /usr/local/bin/kubectl
@ubuntu1804-1:~$
Step 13: Verify the Kubectl Installation
~$ kubectl version
Client Version: version.Info{Major:”1″, Minor:”14″, GitVersion:”v1.14.3″, GitCommit:
“5e53fd6bc17c0dec8434817e69b04a25d8ae0ff0″, GitTreeState:”clean”, BuildDate:
“2019-06-06T01:44:30Z”, GoVersion:”go1.12.5″, Compiler:”gc”, Platform:”linux/amd64″}
Server Version: version.Info{Major:”1″, Minor:”14+”, GitVersion:”v1.14.3-docker-2″,
GitCommit:”7cfcb52617bf94c36953159ee9a2bf14c7fcc7ba”, GitTreeState:”clean”,
BuildDate:”2019-06-06T16:18:13Z”, GoVersion:”go1.12.5″, Compiler:”gc”, Platform:”linux/amd64″
Step 14: List out the Kubernetes Nodes
cse@ubuntu1804-1:~$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
node2 Ready <none> 23h v1.14.3-docker-2
ubuntu1804-1 Ready master 23h v1.14.3-docker-2
Step 15: Enabling Helm and Tiller with UCP
$ kubectl create rolebinding default-view –clusterrole=view –serviceaccount=kube-system
:default –namespace=kube-system
rolebinding.rbac.authorization.k8s.io/default-view created

$ kubectl create clusterrolebinding add-on-cluster-admin –clusterrole=cluster-admin
–serviceaccount=kube-system:default
clusterrolebinding.rbac.authorization.k8s.io/add-on-cluster-admin created
cse@ubuntu1804-1:~$
Step 16: Install Helm
$ curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get > install-helm.sh
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 7001 100 7001 0 0 6341 0 0:00:01 0:00:01 –:–:– 6347
$ chmod u+x install-helm.sh

$ ./install-helm.sh
Downloading https://get.helm.sh/helm-v2.14.3-linux-amd64.tar.gz
Preparing to install helm and tiller into /usr/local/bin
helm installed into /usr/local/bin/helm
tiller installed into /usr/local/bin/tiller
Run ‘helm init’ to configure helm.

cse@ubuntu1804-1:~$ helm init
Creating /home/cse/.helm
Creating /home/cse/.helm/repository
Creating /home/cse/.helm/repository/cache
Creating /home/cse/.helm/repository/local
Creating /home/cse/.helm/plugins
Creating /home/cse/.helm/starters
Creating /home/cse/.helm/cache/archive
Creating /home/cse/.helm/repository/repositories.yaml
Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com
Adding local repo with URL: http://127.0.0.1:8879/charts
$HELM_HOME has been configured at /home/cse/.helm.

Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.

Please note: by default, Tiller is deployed with an insecure ‘allow unauthenticated users’
policy.
To prevent this, run `helm init` with the –tiller-tls-verify flag.
For more information on securing your installation see: https://docs.helm.sh/using_helm/
#securing-your-helm-installation
cse@ubuntu1804-1:~$
Step 17: Verify the Helm Installation
$ helm version
Client: &version.Version{SemVer:”v2.14.3″, GitCommit:”0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085″
, GitTreeState:”clean”}
Server: &version.Version{SemVer:”v2.14.3″, GitCommit:”0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085″
, GitTreeState:”clean”}
Step 18: Deploying MySQL using Helm on Docker Enterprise 3.0
Let’s try out deploying MySQL using HelmPack.
$ helm install –name mysql stable/mysql
NAME: mysql
LAST DEPLOYED: Wed Aug 7 11:43:01 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/ConfigMap
NAME DATA AGE
mysql-test 1 0s

==> v1/PersistentVolumeClaim
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
mysql Pending 0s

==> v1/Secret
NAME TYPE DATA AGE
mysql Opaque 2 0s

==> v1/Service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
mysql ClusterIP 10.96.77.83 <none> 3306/TCP 0s

==> v1beta1/Deployment
NAME READY UP-TO-DATE AVAILABLE AGE
mysql 0/1 0 0 0s

NOTES:
MySQL can be accessed via port 3306 on the following DNS name from within your cluster:
mysql.default.svc.cluster.local

To get your root password run:

MYSQL_ROOT_PASSWORD=$(kubectl get secret –namespace default mysql -o jsonpath=
“{.data.mysql-root-password}” | base64 –decode; echo)

To connect to your database:

1. Run an Ubuntu pod that you can use as a client:

kubectl run -i –tty ubuntu –image=ubuntu:16.04 –restart=Never — bash -il

2. Install the mysql client:

$ apt-get update && apt-get install mysql-client -y

3. Connect using the mysql cli, then provide your password:
$ mysql -h mysql -p

To connect to your database directly from outside the K8s cluster:
MYSQL_HOST=127.0.0.1
MYSQL_PORT=3306

# Execute the following command to route the connection:
kubectl port-forward svc/mysql 3306

mysql -h ${MYSQL_HOST} -P${MYSQL_PORT} -u root -p${MYSQL_ROOT_PASSWORD}

cse@ubuntu1804-1:~$
Step 19: Listing out the Releases
The helm list command lists all of the releases. By default, it lists only releases that are deployed or failed. Flags like ‘–deleted’ and ‘–all’ will alter this behavior. Such flags can be combined: ‘–deleted –failed’. By default, items are sorted alphabetically. Use the ‘-d’ flag to sort by release date.
$ helm list
NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE
mysql 1 Wed Aug 7 11:43:01 2019 DEPLOYED mysql-1.3.0 5.7.14 default

$ kubectl get po,deploy,svc
NAME READY STATUS RESTARTS AGE
pod/mysql-6f6bff58d8-t2kwm 1/1 Running 0 5m35s

NAME READY UP-TO-DATE AVAILABLE AGE
deployment.extensions/mysql 1/1 1 0 5m35s

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 28h
service/mysql ClusterIP 10.96.77.83 <none> 3306/TCP 5m35s
cse@ubuntu1804-1:~$
With DKS, you can use Helm flawlessly with UCP under Docker Enterprise 3.0.
Kubernetes, On-Premises
Now you have Kubernetes running on-premises. You can do a lot from here, and I’ll cover some possibilities in the rest of this series.
You may also want to experiment with designing your first application in Kubernetes. Bill Mills from the Docker training team wrote a great blog series recently covering just that. I highly recommend checking it out starting with part 1 here.

The Rise of On-Premises Certified #Kubernetes Cluster with Docker Enterprise 3.0 & DKS by #DockerCaptain @ajeetsrainaClick To Tweet

Have a look at these resources if you’re looking to learn more about Docker Enterprise 3.0 and Kubernetes:

Try out Play with Kubernetes.
Try the Docker Kubernetes Service.
Learn about Kubernetes Lifecycle Management with DKS.

The post Building Your First Certified Kubernetes Cluster On-Premises, Part 1 appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

1. Oktober 2019

da Agency

Building Your First Certified Kubernetes Cluster On-Premises, Part 1

Deploying certified Kubernetes Cluster using Docker Enterprise 3.0 running on a Bare Metal System
Support of Kubernetes on Windows Server 2019 with Docker Enterprise 3.0
Implementing Persistent storage for Kubernetes workload using iSCSI
Implementing Cluster Ingress for Kubernetes
Deploying Istio Service Mesh under Docker Enterprise 3.0