Tips for Troubleshooting Apps in Production with Docker Datacenter

If you have been using Docker for some time, after the initial phases of building Dockerfiles and running a container here and there, the real work begins in building, deploying and operating multi-container applications in a production environment.  Are you operationally ready to take your application to production? Docker Datacenter provides an integrated management framework for your Dockerized environment and applications and when coupled with clear strategies in approaching and resolving anomalies, IT ops teams can be assured in successfully operationalizing Docker.
Let’s use a sports metaphor to approach troubleshooting:

Pre-Game will cover the planning phase for your applications
Game Time will cover troubleshooting tools available in Docker Datacenter
Post-Game will discuss complementary tools to aid in ongoing insights

Pre-Game
Whether or not you are sports fan, you can appreciate the importance of the planning out any task. This is no different than what you would do for your applications. Health checks are a great way to provide a deeper level of insight into how your application is performing. Since Docker 1.12 there is a new HEALTHCHECK directive. We can use this directive to signal to the Docker Engine whether or not the application is healthy.
There are a two ways to implement the HEALTHCHECK directive. The first way is use the directive in the Dockerfile. I prefer this method since the app and the health check are coupled together. Here is an example of a Dockerfile with the HEALTHCHECK directive :
FROM alpine
RUN apk -U upgrade && apk add python curl &&
apk add py-pip &&
pip install –upgrade pip &&
pip install flask redis pymongo &&
rm -rf /var/cache/apk/*
WORKDIR /code
ADD . /code
EXPOSE 5000
HEALTHCHECK CMD curl -f http://localhost:5000/ || exit 1
CMD [“python”, “app.py”]

The second way is using the docker run command. https://docs.docker.com/engine/reference/run/#/healthcheck. Here is an example of the run command :
docker run –name=test -d –health-cmd=’stat /etc/passwd || exit 1′ –health-interval=2s busybox sleep 1d
This method can actually supersede the Dockerfile method. Both methods are very useful. Here is an example output with the heatlh :
clemenko13:orientation clemenko$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4cbabba22d31 clemenko/orient_flask “python app.py” 15 minutes ago Up 15 minutes (healthy) 0.0.0.0:5000->5000/tcp orientation_app_1

You can even write wrappers to report this back.
And in the image below, you can see that Docker Datacenter has a visual for the HEALTHCHECK within the container info itself.

Game Time
Whether or not you have the healthz endpoint setup, Docker Datacenter has some great troubleshooting tools built right in.
Let’s start with the container details.
In Docker Datacenter, you can click on the container to bring up the details and other items. There is a ton of good details here like Status, Healthcheck, Node, Networks and Ports. Here is an example with an active Healthcheck.

Moving on to logging.
With Docker Datacenter you have a few choices with logging. You can let Docker Datacenter handle it for you, or send all the logs remotely for the whole engine. In the Docker Datacenter UI, you are able to drill into each container’s logs.

If you want to use something like the syslog driver for remote logging you can modify the logging configuration from the Docker Datacenter admin settings. More info on the log drivers can be found here.

Next we can dive into the container itself.
Docker Datacenter has the ability to attach to a console session of the container remotely. You can use the console to dive into the running container. This is very useful if you need to check files, processes, settings or even ports. The trick with the console UI is that you need to have a shell inside your image. Most images will have sh or bash as part of their base image. Similar to viewing the container logs you will see a “Console” tab on the container’s info page. Notice it will try and use sh by default :

NOTE: By using the RBAC feature in Docker Datacenter you can configure access in many ways. For example you can give developers access through the GUI but not through SSH.
Next we need to talk about networking.
Issues can arise once your application is live and running. If you run into networking related issues, there are two good ways to troubleshoot through the containers console or the sidekick method. The console method should be the first step. Simply console into the container and curl/ping around. What if you don’t have curl in your image. Well simple docker run a base image attached to the same network overlay. With that base image you should be able to add ANY binaries that are needed for troubleshooting the network. You can even pre-build one for use within your infrastructure.
It is worth noting that the same container info page also has stats. The stats tab only displays the current stats for CPU, MEMORY, and NETWORK. However this can be useful is seeing if there are any bottlenecks.

Post Game and Wrap-up.
Start with the HEALTHCHECK endpoint. Check the logs, either remotely or locally. Then move onto the console to introspect the running container. Aggregating your logs can give you insight into all your apps and hosts at the same time. Remote logging to external systems like ELK or Splunk can give you that aggregate view. Stats can also be good for aggregation. CAdvisor or Sysdig’s containers can be plumbed up for combined historical metrics.
Hopefully you have a much better understanding of how to troubleshoot your running Dockerized applciations.
More resources for you:

See What’s New and Learn more about Docker Datacenter
Sign up for a free 30 day trial
Check out the Docker knowledge base for more tips

Tips for troubleshooting apps in production To Tweet

The post Tips for Troubleshooting Apps in Production with Docker Datacenter appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

What’s New in Docker Datacenter with Engine 1.12 – Demo Q&A

Last week we announced the latest release of (DDC) with Engine 1.12 integration, which includes Universal Control Plane (UCP) 2.0 and Docker Trusted Registry (DTR) 2.1. Now, IT operations teams can manage and secure their environment more effectively and developers can self-service select from an even more secure image base. Docker Datacenter with Engine 1.12 boasts improvements in orchestration and operations, end to end security (image signing, policy enforcement, mutual TLS encryption for clusters), enables Docker service deployments and includes an enhanced UI. Customers also have backwards compatibility for Swarm 1.x and Compose.

 
To showcase some of these new features we hosted a webinar where we provided an overview of Docker Datacenter, talked through some of the new features and showed a live demo of solution. Watch the recording of the webinar below:
 

 
We hosted a Q&A session at the end of the webinar and have included some of the most common audience questions  received.
Audience Q&A
Can I still deploy run and deploy my applications built with a previous Docker Engine version?
Yes. UCP 2.0 automatically sets up and manages a Swarm cluster alongside the native built-in swarm-mode cluster from Engine 1.12 on the same set of nodes. This means that when you use “docker run” commands, they are handled by the Swarm 1.x part of the UCP cluster and thus ensures full backwards compatibility with your existing Docker applications. The best part is, no additional product installation or configuration is required by the admin to make this work.In addition to this, previous versions of the Docker Engine (1.10 and 1.11) will still be supported as part of Docker Datacenter.
 
Will Docker Compose continue to work in Docker Datacenter?  I.e Deploy containers to multiple hosts in a DDC cluster, as opposed to only on a single host?
In UCP, “docker-compose up” will deploy to multiple hosts on the cluster. This is different from an open-source Engine 1.12 swarm-mode, where it will only deploy on a single node, because UCP offers full backwards compatibility (using the parallel Swarm 1.x cluster, as described above). Note that you will have to use Compose v2 in order to deploy across multiple hosts, as Compose v1 format does not support multi-host deployment.
 
For the built in HTTP routing mesh, which External LB&;s are supported? Nginx, HAProxy, AWS EC2 Elastic LB? Does this work similar to what Interlock was doing?
The experimental HTTP routing mesh (HRM) feature is focused on providing correct routing between hostnames and services, so it will  work across any of the above load balancers, as long as you configure them appropriately for this purpose.
The HRM and Interlock LB/SD feature sets provide similar capabilities but for different application architectures. HRM is used for swarm-mode based services, while Interlock is used for non-swarm-mode “docker run” containers.
For more information on these features, check out our blog post on DDC networking updates and the updated reference architecture linked within that post.
 
Will the HTTP routing mesh feature be available also in the open source free version of the docker engine?
Docker Engine 1.12 (open-source) contains the TCP-based routing mesh, which allows you to route based on ports. Docker Datacenter also provides the HTTP routing mesh feature which extends the open-source feature to allow you to route based on hostnames.
 
What is “docker service” used for and why?
A Docker service is a construct within swarm-mode that consists of a group of containers (“tasks”) from the same image. Services follow a declarative model that allows you to specify the desired state of your application: you specify how many instances of the container image you want, and swarm-mode ensures that those instances are deployed on the cluster. If any of those instances go down (e.g. because a host is lost), swarm-mode automatically reschedules them elsewhere on the cluster. The service also provides integrated load balancing and service discovery for its container instances.
 
What type of monitoring of host health is built in?
The new swarm-mode in Docker Engine 1.12 uses a RAFT-based consensus algorithm to determine the health of nodes in the cluster. Each swarm manager sends regular pings to workers (and to other managers) in order to determine their current status. If the pings return an unhealthy response or do not meet the latency minimums for the cluster (configurable in the settings), then that node might be declared unhealthy and containers will be scheduled elsewhere in the cluster. In Universal Control Plane (UCP), the status of nodes is described in detail in the web UI on the dashboard and Nodes pages.
 
What kind of role based access controls (RBAC) are available for networks and load balancing features?
The previous version of UCP (1.1) had the ability to provide granular label-based access control for containers. We’ve since expanded that granular access control to include both services and networks, so you can use labels to define which networks a team of users has access to, and what level of access that team has. The load balancing features make use of both services and networks so will be access controlled through those resources.
 
Is it possible to enforce a criteria that only allows production DTR run only containers that are signed?
Yes, you can accomplish this using a combination of features in the new version of Docker Datacenter. DTR 2.1 contains a Notary server (Docker Content Trust), which allows you to provide your users cryptographic keys to sign images. UCP 2.0 has the ability to run only signed images on the cluster. Furthermore, you can use “delegations” to define which teams must sign the image prior to it being deployed; for example in a low security cluster you could allows any UCP user to sign, whereas in production, you might require signatures from Release Management, Security, and Developer teams. Learn more about running images with Docker Content Trust here.
 
As a very large enterprise doing various POC&8217;s for Docker, one of the big questions is vulnerabilities in the open source code that can be part of the base images. Is there anything that Docker is developing to counter this?
Earlier this year, we announced Docker Security Scanning, which provides a detailed security profile of Docker images for risk management and software compliance purposes. Docker Security Scanning is currently available for private repositories in Docker Cloud private and coming soon to Docker Datacenter.
 
Is there any possibility to trace which user is accessing a container?
Yes, you can use audit logging. To provide auditing of your cluster, you can utilize UCP’s Remote Log Server feature. This allows you to send system debug information to a syslog server of your choice, including a full list of all commands run against the UCP cluster. This would include information such as which user attempted to deploy or access a container.
 
What checks does the new DDC have for potential noisy neighbor container scenarios, or for rogue containers that can potentially hog the underlying infrastructure?
One of the ways you can provide a check against noisy neighbor scenarios is through the use of runtime resource constraints. These allow you to set limits on how much system resources (e.g. cpu, memory) that any given container is allowed to use. These are configurable within the UI.
 
Do you have a trial license for Docker Datacenter ?
We offer a free 30-day trial of Docker Datacenter. Trial software  can be accessed by visiting the Docker Store &; www.docker.com/trial
 
For pricing, is a node defined as a host machine or a container?
The subscription is licensed and priced on a per node per year basis. A node is anything with the Docker Commercially Supported (CS) Engine installed on it. It could be a bare metal server, cloud instance or within a virtual machine. More pricing details are available here.
 
More Resources:

Request a demo: of the latest Docker Datacenter
See What’s New in Docker Datacenter
Learn more by visiting the Docker Datacenter webpage
Sign up for a free 30 day trial

Check out the FAQ from last week’s Docker Datacenter demo! To Tweet

The post What’s New in Docker Datacenter with Engine 1.12 &8211; Demo Q&;A appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/