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

Docker Datacenter customer, Shawn Bower of Cornell University recently shared their experiences in containerizing Confluence as being the start of their Docker journey.
Through that project they were able to demonstrate a 10X savings in application maintenance, reduce the time to build a disaster recovery plan from days to 30 minutes and improve the security profile of their Confluence deployment. This change allowed the Cloudification team that Shawn leads to start spending the majority of their time helping Cornelians to use technology to be innovative.
Since the original blog was posted, there’s been a lot of requests to get the pragmatic info on how Cornell actually did this project. In the post below, Shawn provides detailed instructions on how Confluence is containerized and how the Docker workflow is integrated with Puppet.

Written by Shawn Bower
As we started our Journey to move Confluence to the cloud using Docker we were emboldened by the following post from Atlassian. We use many of the Atlassian products and love how well integrated they are. In this post I will walk you through the process we used to get Confluence in a container and running.
First we needed to craft a Dockerfile. At Cornell we used image inheritance which enables our automated patching and security scanning process. We start with the cannonical ubuntu image: https://hub.docker.com/_/ubuntu/ and then build on defaults used here at Cornell. Our base image is available publicly on github here: https://github.com/CU-CommunityApps/docker-base.
Let’s take a look at the Dockerfile.
FROM ubuntu:14.04

# File Author / Maintainer
MAINTAINER Shawn Bower <my email address>

# Install.
RUN
apt-get update && apt-get install –no-install-recommends -y
build-essential
curl
git
unzip
vim
wget
ruby
ruby-dev
#clamav-daemon
openssh-client &&
rm -rf /var/lib/apt/lists/*

RUN rm /etc/localtime
RUN ln -s /usr/share/zoneinfo/America/New_York /etc/localtime

Clamav stuff
RUN freshclam -v &&
mkdir /var/run/clamav &&
chown clamav:clamav /var/run/clamav &&
chmod 750 /var/run/clamav

COPY conf/clamd.conf /etc/clamav/clamd.conf

RUN echo “gem: –no-ri –no-rdoc” > ~/.gemrc &&
gem install json_pure -v 1.8.1 &&
gem install puppet -v 3.7.5 &&
gem install librarian-puppet -v 2.1.0 &&
gem install hiera-eyaml -v 2.1.0

# Set environment variables.
ENV HOME /root

# Define working directory.
WORKDIR /root

# Define default command.
CMD [“bash”]

At Cornell we use Puppet for configuration management so we bake that directly into our base image. We do a few other things like setting the timezone and installing the clamav agent as we have some applications that use that for virus scanning. We have an automated project in Jenkins that pulls that latest ubuntu:14.04 image from Docker Hub and then builds this base image every weekend. Once the base image is built we tag it with ‘latest’, a time stamp tag and automatically push it to our local Docker Trusted Registry. This allows the brave to pull in patches continuously while allowing others to pin to a specific version until they are ready to migrate. From that image we create a base Java image which installs Oracle’s JVM.
The Dockerfile is available here and explained below.
# Pull base image.
FROM DTR Repo path /cs/base

# Install Java.
RUN
apt-get update &&
apt-get -y install software-properties-common &&
add-apt-repository ppa:webupd8team/java -y &&
apt-get update &&
echo “oracle-java8-installer shared/accepted-oracle-license-v1-1 select true” | sudo debconf-set-selections &&
apt-get install -y oracle-java8-installer &&
apt-get install oracle-java8-set-default &&
rm -rf /var/lib/apt/lists/*

# Define commonly used JAVA_HOME variable
ENV JAVA_HOME /usr/lib/jvm/java-8-oracle

# Define working directory.
WORKDIR /data

# Define default command.
CMD [“bash”]

The same automated patching process is followed for the Java image as with the base image. The Java image is automatically built after the base imaged and tagged accordingly so there is a matching set of base and java8. Now that we have our Java image we can layer on Confluence. Our Confluence repository is private but the important bits of the Dockerfile are below.
FROM DTR Repo path for cs/java8

# Configuration variables.
ENV CONF_HOME /var/local/atlassian/confluence
ENV CONF_INSTALL /usr/local/atlassian/confluence
ENV CONF_VERSION 5.8.18

ARG environment=local

# Install Atlassian Confluence and helper tools and setup initial home
# directory structure.
RUN set -x
&& apt-get update –quiet
&& apt-get install –quiet –yes –no-install-recommends libtcnative-1 xmlstarlet
&& apt-get clean
&& mkdir -p “${CONF_HOME}”
&& chmod -R 700 “${CONF_HOME}”
&& chown daemon:daemon “${CONF_HOME}”
&& mkdir -p “${CONF_INSTALL}/conf”
&& curl -Ls “http://www.atlassian.com/software/confluence/downloads/binary/atlassian-confluence-${CONF_VERSION}.tar.gz” | tar -xz –directory “${CONF_INSTALL}” –strip-components=1 –no-same-owner
&& chmod -R 700 “${CONF_INSTALL}/conf”
&& chmod -R 700 “${CONF_INSTALL}/temp”
&& chmod -R 700 “${CONF_INSTALL}/logs”
&& chmod -R 700 “${CONF_INSTALL}/work”
&& chown -R daemon:daemon “${CONF_INSTALL}/conf”
&& chown -R daemon:daemon “${CONF_INSTALL}/temp”
&& chown -R daemon:daemon “${CONF_INSTALL}/logs”
&& chown -R daemon:daemon “${CONF_INSTALL}/work”
&& echo -e “nconfluence.home=$CONF_HOME” >> “${CONF_INSTALL}/confluence/WEB-INF/classes/confluence-init.properties”
&& xmlstarlet ed –inplace
–delete “Server/@debug”
–delete “Server/Service/Connector/@debug”
–delete “Server/Service/Connector/@useURIValidationHack”
–delete “Server/Service/Connector/@minProcessors”
–delete “Server/Service/Connector/@maxProcessors”
–delete “Server/Service/Engine/@debug”
–delete “Server/Service/Engine/Host/@debug”
–delete “Server/Service/Engine/Host/Context/@debug”
“${CONF_INSTALL}/conf/server.xml”

# bust cache
ADD version /version

# RUN Puppet
WORKDIR /
COPY Puppetfile /
COPY keys/ /keys

RUN mkdir -p /root/.ssh/ &&
cp /keys/id_rsa /root/.ssh/id_rsa &&
chmod 400 /root/.ssh/id_rsa &&
touch /root/.ssh/known_hosts &&
ssh-keyscan github.com >> /root/.ssh/known_hosts &&
librarian-puppet install &&
puppet apply –modulepath=/modules – hiera_config=/modules/confluence/hiera.yaml

–environment=${environment} -e “class { confluence::app': }” &&
rm -rf /modules &&
rm -rf /Puppetfile* &&
rm -rf /root/.ssh &&
rm -rf /keys

USER daemon:daemon

# Expose default HTTP connector port.
EXPOSE 8080

VOLUME [“/opt/atlassian/confluence/logs”]

# Set the default working directory as the installation directory.
WORKDIR /var/atlassian/confluence

# Run Atlassian Confluence as a foreground process by default.
CMD [“/opt/atlassian/confluence/bin/catalina.sh”, “run”]

We bring down the install media from Atlassian, explode that into the install path and do a bit of cleanup on some of the XML configs. We use Docker build cache for that part of the process becauses it does not change often. After the Confluence installation we bust the cache by adding a version file which changes each time the build runs in Jenkins. This ensuers that Puppet will run in the container and configure the environment. Puppet is used to lay down environment (dev, test, prod, etc.) configuration and use a docker build argument called ‘environment.’ This allows us to bake everything needed to run Confluence into the image so we can launch it on any machine with no extra configuration. Whether to store the configuration in the image or outside is a contested subject for sure, but our decision was to store all configurations directly in the image. We believe this ensures the highest level of portability.
Here are some general rules we follow with Docker

Use base images that are a part of the automated patching
Follow Dockerfile best practices
Keep the base infrastructure in a Dockerfile, and environment specific information in Puppet
Build one process per container
Keep all components of the stack in one repository
If the stack has multiple components (ie, apache, tomcat) they should live in the same repository
Use subdirectories for each component

Hope you enjoyed this post and gets you containerizing some vendored apps. This is just the beginning as we recently moved a legacy coldfusion app into Docker – almost anything can probably be containerized!

Tips on how to dockerize @atlassian @Confluence by @Cornell’s @drizzt51Click To Tweet

More Resources

Try Docker Datacenter free for 30 days
Learn more about Docker Datacenter
Read the blog post &8211; It all started with containerizing Confluence at Cornell
Watch the webinar featuring Shawn and Docker at Cornell

The post How To Dockerize Vendor Apps like Confluence appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

5. Oktober 20165. Oktober 2016

da Agency

Dynamic Provisioning and Storage Classes in Kubernetes

Storage is a critical part of running containers, and Kubernetes offers some powerful primitives for managing it. Dynamic volume provisioning, a feature unique to Kubernetes, allows storage volumes to be created on-demand. Without dynamic provisioning, cluster administrators have to manually make calls to their cloud or storage provider to create new storage volumes, and then create PersistentVolume objects to represent them in Kubernetes. The dynamic provisioning feature eliminates the need for cluster administrators to pre-provision storage. Instead, it automatically provisions storage when it is requested by users. This feature was introduced as alpha in Kubernetes 1.2, and has been improved and promoted to beta in the latest release, 1.4. This release makes dynamic provisioning far more flexible and useful.What’s New?The alpha version of dynamic provisioning only allowed a single, hard-coded provisioner to be used in a cluster at once. This meant that when Kubernetes determined storage needed to be dynamically provisioned, it always used the same volume plugin to do provisioning, even if multiple storage systems were available on the cluster. The provisioner to use was inferred based on the cloud environment – EBS for AWS, Persistent Disk for Google Cloud, Cinder for OpenStack, and vSphere Volumes on vSphere. Furthermore, the parameters used to provision new storage volumes were fixed: only the storage size was configurable. This meant that all dynamically provisioned volumes would be identical, except for their storage size, even if the storage system exposed other parameters (such as disk type) for configuration during provisioning.Although the alpha version of the feature was limited in utility, it allowed us to “get some miles” on the idea, and helped determine the direction we wanted to take.The beta version of dynamic provisioning, new in Kubernetes 1.4, introduces a new API object, StorageClass. Multiple StorageClass objects can be defined each specifying a volume plugin (aka provisioner) to use to provision a volume and the set of parameters to pass to that provisioner when provisioning. This design allows cluster administrators to define and expose multiple flavors of storage (from the same or different storage systems) within a cluster, each with a custom set of parameters. This design also ensures that end users don’t have to worry about the the complexity and nuances of how storage is provisioned, but still have the ability to select from multiple storage options.How Do I use It?Below is an example of how a cluster administrator would expose two tiers of storage, and how a user would select and use one. For more details, see the reference and example docs.Admin ConfigurationThe cluster admin defines and deploys two StorageClass objects to the Kubernetes cluster:kind: StorageClassapiVersion: extensions/v1beta1metadata: name: slowprovisioner: kubernetes.io/gce-pdparameters: type: pd-standardThis creates a storage class called “slow” which will provision standard disk-like Persistent Disks.kind: StorageClassapiVersion: extensions/v1beta1metadata: name: fastprovisioner: kubernetes.io/gce-pdparameters: type: pd-ssdThis creates a storage class called “fast” which will provision SSD-like Persistent Disks.User RequestUsers request dynamically provisioned storage by including a storage class in their PersistentVolumeClaim. For the beta version of this feature, this is done via the volume.beta.kubernetes.io/storage-class annotation. The value of this annotation must match the name of a StorageClass configured by the administrator.To select the “fast” storage class, for example, a user would create the following PersistentVolumeClaim:{ “kind”: “PersistentVolumeClaim”, “apiVersion”: “v1″, “metadata”: { “name”: “claim1″, “annotations”: { “volume.beta.kubernetes.io/storage-class”: “fast” } }, “spec”: { “accessModes”: [ “ReadWriteOnce” ], “resources”: { “requests”: { “storage”: “30Gi” } } }} This claim will result in an SSD-like Persistent Disk being automatically provisioned. When the claim is deleted, the volume will be destroyed.Defaulting BehaviorDynamic Provisioning can be enabled for a cluster such that all claims are dynamically provisioned without a storage class annotation. This behavior is enabled by the cluster administrator by marking one StorageClass object as “default”. A StorageClass can be marked as default by adding the storageclass.beta.kubernetes.io/is-default-class annotation to it.When a default StorageClass exists and a user creates a PersistentVolumeClaim without a storage-class annotation, the new DefaultStorageClass admission controller (also introduced in v1.4), automatically adds the class annotation pointing to the default storage class.Can I Still Use the Alpha Version?Kubernetes 1.4 maintains backwards compatibility with the alpha version of the dynamic provisioning feature to allow for a smoother transition to the beta version. The alpha behavior is triggered by the existance of the alpha dynamic provisioning annotation (volume.alpha.kubernetes.io/storage-class). Keep in mind that if the beta annotation (volume.beta.kubernetes.io/storage-class) is present, it takes precedence, and triggers the beta behavior.Support for the alpha version is deprecated and will be removed in a future release.What’s Next?Dynamic Provisioning and Storage Classes will continue to evolve and be refined in future releases. Below are some areas under consideration for further development.Standard Cloud ProvisionersFor deployment of Kubernetes to cloud providers, we are considering automatically creating a provisioner for the cloud’s native storage system. This means that a standard deployment on AWS would result in a StorageClass that provisions EBS volumes, a standard deployment on Google Cloud would result in a StorageClass that provisions GCE PDs. It is also being debated whether these provisioners should be marked as default, which would make dynamic provisioning the default behavior (no annotation required).Out-of-Tree ProvisionersThere has been ongoing discussion about whether Kubernetes storage plugins should live “in-tree” or “out-of-tree”. While the details for how to implement out-of-tree plugins is still in the air, there is a proposal introducing a standardized way to implement out-of-tree dynamic provisioners.How Do I Get Involved?If you’re interested in getting involved with the design and development of Kubernetes Storage, join the Kubernetes Storage Special-Interest-Group (SIG). We’re rapidly growing and always welcome new contributors.– Saad Ali, Software Engineer, GoogleDownload KubernetesGet involved with the Kubernetes project on GitHub Post questions (or answer questions) on Stack Overflow Connect with the community on SlackFollow us on Twitter @Kubernetesio for latest updates
Quelle: kubernetes

4. Oktober 20164. Oktober 2016

da Agency

Introducing InfraKit, an open source toolkit for creating and managing declarative, self-healing infrastructure

Written by Bill Farner and David Chung
Docker’s mission is to build tools of mass innovation, starting with a programmable layer for the Internet that enables developers and IT operations teams to build and run distributed applications. As part of this mission, we have always endeavored to contribute software plumbing toolkits back to the community, following the UNIX philosophy of building small loosely coupled tools that are created to simply do one thing well. As Docker adoption has grown from 0 to 6 billion pulls, we have worked to address the needs of a growing and diverse set of distributed systems users. This work has led to the creation of many infrastructure plumbing components that have been contributed back to the community.

It started in 2014 with libcontainer and libnetwork. In 2015 we created runC and co-founded OCI with an industry-wide set of partners to provide a standard for container runtimes, a reference implementation based on libcontainer, and notary, which provides the basis for Docker Content Trust. From there we added containerd, a daemon to control runC, built for performance and density. Docker Engine was refactored so that Docker 1.11 is built on top of containerd and runC, providing benefits such as the ability to upgrade Docker Engine without restarting containers. In May 2016 at OSCON, we open sourced HyperKit, VPNKit and DataKit, the underlying components that enable us to deeply integrate Docker for Mac and Windows with the native Operating System. Most recently, in June, we unveiled SwarmKit, a toolkit for scheduling tasks and the basis for swarm mode, the built-in orchestration feature in Docker 1.12.
With SwarmKit, Docker introduced a declarative management toolkit for orchestrating containers. Today, we are doing the same for infrastructure. We are excited to announce InfraKit, a declarative management toolkit for orchestrating infrastructure. Solomon Hykes open sourced it today during his keynote address at LinuxCon Europe. You can find the source code at https://github.com/docker/infrakit

InfraKit Origins
Back in June at DockerCon, we introduced Docker for AWS and Azure beta to simplify the IT operations experience in setting up Docker and to optimally leverage the native capabilities of the respective cloud environment. To do this, Docker provided deep integrations into these platforms’ capabilities for storage, networking and load balancing.
In the diagram below, the architecture for these versions includes platform-specific network and storage plugins, but also a new component specific to infrastructure management.
While working on Docker for AWS and Azure, we realized the need for a standard way to create and manage infrastructure state that was portable across any type of infrastructure, from different cloud providers to on-prem. One challenge is that each vendor has differentiated IP invested in how they handle certain aspects of their cloud infrastructure. It is not enough to just provision five servers;what IT ops teams need is a simple and consistent way to declare the number of servers, what size they should be, and what sort of base software configuration is required. And in the case of server failures (especially unplanned), that sudden change needs to be reconciled against the desired state to ensure that any required servers are re-provisioned with the necessary configuration. We started InfraKit to solves these problems and to provide the ability to create a self healing infrastructure for distributed systems.

InfraKit Internals
InfraKit breaks infrastructure automation down into simple, pluggable components for declarative infrastructure state, active monitoring and automatic reconciliation of that state. These components work together to actively ensure the infrastructure state matches the user’s specifications. InfraKit emphasizes primitives for building self-healing infrastructure but can also be used passively like conventional tools.
InfraKit at the core consists of a set of collaborating, active processes. These components are called plugins and different plugins can be written to meet different needs. These plugins are active controllers that can look at current infrastructure state and take action when the state diverges from user specification.
Initially, these plugins are implemented as servers listening on unix sockets and communicate using HTTP. By nature, the plugin interface definitions are language agnostic so it&8217;s possible to implement a plugin in a language other than Go. Plugins can be packaged and deployed differently, such as with Docker containers.
Plugins are the active components that provide the behavior for the primitives that InfraKit supports. InfraKit supports these primitives: groups, instances, and flavors. They are active components running as plugins.
Groups
When managing infrastructure like computing clusters, Groups make good abstraction, and working with groups is easier than managing individual instances. For example, a group can be made up of a collection of machines as individual instances. The machines in a group can have identical configurations (replicas, or so-called “cattle”). They can also have slightly different configurations and properties like identity,ordering, and persistent storage (as members of a quorum or so-called “pets”).
Instances
Instances are members of a group. An instance plugin manages some physical resource instances. It knows only about individual instances and nothing about Groups. Instance is technically defined by the plugin, and need not be a physical machine at all. As part of the toolkit, we have included examples of instance plugins for Vagrant and Terraform. These examples show that it’s easy to develop plugins. They are also examples of how InfraKit can play well with existing system management tools while extending their capabilities with active management. We envision more plugins in the future – for example plugins for AWS and Azure.
Flavors
Flavors help distinguish members of one group from another by describing how these members should be treated. A flavor plugin can be thought of as defining what runs on an Instance. It is responsible for configuring the physical instance and for providing health-check in an application-aware way. It is also what gives the member instances properties like identity and ordering when they require special handling. Examples of flavor plugins include plain servers, Zookeeper ensemble members, and Docker swarm mode managers.
By separating provisioning of physical instances and configuration of applications into Instance and Flavor plugins, application vendors can directly develop a Flavor plugin, for example, MySQL, that can work with a wide array of instance plugins.
Active Monitoring and Automatic Reconciliation
The active self-healing aspect of InfraKit sets it apart from existing infrastructure management solutions, and we hope it will help our industry build more resilient and self-healing systems. The InfraKit plugins themselves continuously monitor at the group, instance and flavor level for any drift in configuration and automatically correct it without any manual intervention.

The group plugin checks on the size, overall health of the group and decides on strategies for updating.
The instance plugin monitors for the physical presence of resources.
The flavor plugin can make additional determination beyond presence of the resource. For example the swarm mode flavor plugin would check not only that a swarm member node is up, but that the node is also a member of the cluster. This provides an application-specific meaning to a node’s “health.”

This active monitoring and automatic reconciliation brings a new level of reliability for distributed systems.
The diagram below shows an example of how InfraKit can be used. There are three groups defined; one for a set of stateless cattle instances, one for a set of stateful and uniquely named pet instances and one defined for the Infrakit manager instances themselves. Each group will be monitored for their declared infrastructure state and reconciled independently of the other groups. For example, if one of the nodes (blue and yellow) in the cattle group goes down, a new one will be started to maintain the desired size. When the leader host (M2) running InfraKit goes down, a new leader will be elected (from the standby M1 and M3). This new leader will go into action by starting up a new member to join the quorum to ensure availability and desired size of the group.

InfraKit, Docker and Community
InfraKit was born out of our engineering efforts around Docker for AWS and Azure and future versions will see further integration of InfraKit into Docker and those environments, continuing the path building Docker with a set of reusable components.
As the diagram below shows, Docker Engine is already made up of a number of infrastructure plumbing components mentioned earlier. The components are not only available separately to the community, but integrated together as the Docker Engine. In a future release, InfraKit will also become part of the Docker Engine.
With community participation, we aim to evolve InfraKit into exciting new areas beyond managing nodes in a cluster. There’s much work ahead of us to build this into a cohesive framework for managing infrastructure resources, physical, virtual or containerized, from cluster nodes to networks to load balancers and storage volumes.
We are excited to open source InfraKit and invite the community to participate in this project:

Help define and implement new and interesting plugins
Instance plugins to support different infrastructure providers
Flavor plugins to support a variety of systems like etcd or mysql clusters
Group controller plugins like metrics-driven auto scaling and more
Help define interfaces and implement new infrastructure resource types for things like load balancers, networks and storage volume provisioners

Check out the InfraKit repository README for more info, a quick tutorial and to start experimenting — from plain files to Terraform integration to building a Zookeeper ensemble. Have a look, explore, and send us a PR or open an issue with your ideas!

Introducing InfraKit: A new open source toolkit for declarative infrastructureClick To Tweet

More Resources:

Check out all the Infrastructure Plumbing projects
Sign up for Docker for AWS or Docker for Azure
Try Docker today

The post Introducing InfraKit, an open source toolkit for creating and managing declarative, self-healing infrastructure appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

4. Oktober 20164. Oktober 2016

da Agency

How we improved Kubernetes Dashboard UI in 1.4 for your production needs

With the release of Kubernetes 1.4 last week, Dashboard – the official web UI for Kubernetes – has a number of exciting updates and improvements of its own. The past three months have been busy ones for the Dashboard team, and we’re excited to share the resulting features of that effort here. If you’re not familiar with Dashboard, the GitHub repo is a great place to get started.A quick recap before unwrapping our shiny new features: Dashboard was initially released March 2016. One of the focuses for Dashboard throughout its lifetime has been the onboarding experience; it’s a less intimidating way for Kubernetes newcomers to get started, and by showing multiple resources at once, it provides contextualization lacking in kubectl (the CLI). After that initial release though, the product team realized that fine-tuning for a beginner audience was getting ahead of ourselves: there were still fundamental product requirements that Dashboard needed to satisfy in order to have a productive UX to onboard new users too. That became our mission for this release: closing the gap between Dashboard and kubectl by showing more resources, leveraging a web UI’s strengths in monitoring and troubleshooting, and architecting this all in a user friendly way.Monitoring GraphsReal time visualization is a strength that UI’s have over CLI’s, and with 1.4 we’re happy to capitalize on that capability with the introduction of real-time CPU and memory usage graphs for all workloads running on your cluster. Even with the numerous third-party solutions for monitoring, Dashboard should include at least some basic out-of-the box functionality in this area. Next up on the roadmap for graphs is extending the timespan the graph represents, adding drill-down capabilities to reveal more details, and improving the UX of correlating data between different graphs.LogsBased on user research with Kubernetes’ predecessor Borg and continued community feedback, we know logs are tremendously important to users. For this reason we’re constantly looking for ways to improve these features in Dashboard. This release includes a fix for an issue wherein large numbers of logs would crash the system, as well as the introduction of the ability to view logs by date.Showing More ResourcesThe previous release brought all workloads to Dashboard: Pods, Pet Sets, Daemon Sets, Replication Controllers, Replica Set, Services, & Deployments. With 1.4, we expand upon that set of objects by including Services, Ingresses, Persistent Volume Claims, Secrets, & Config Maps. We’ve also introduced an “Admin” section with the Namespace-independent global objects of Namespaces, Nodes, and Persistent Volumes. With the addition of roles, these will be shown only to cluster operators, and developers’ side nav will begin with the Namespace dropdown.Like glue binding together a loose stack of papers into a book, we needed some way to impose order on these resources for their value to be realized, so one of the features we’re most excited to announce in 1.4 is navigation.NavigationIn 1.1, all resources were simply stacked on top of each other in a single page. The introduction of a side nav provides quick access to any aspect of your cluster you’d like to check out. Arriving at this solution meant a lot of time put toward thinking about the hierarchy of Kubernetes objects – a difficult task since by design things fit together more like a living organism than a nested set of linear relationships. The solution we’ve arrived at balances the organizational need for grouping and desire to retain a bird’s-eye view of as much relevant information as possible. The design of the side nav is simple and flexible, in order to accommodate more resources in the future. Its top level objects (e.g. “Workloads”, “Services and Discovery”) roll up their child objects and will eventually include aggregated data for said objects.Closer Alignment with Material DesignDashboard follows Google’s Material design system, and the implementation of those principles is refined in the new UI: the global create options have been reduced from two choices to one initial “Create” button, the official Kubernetes logo is displayed as an SVG rather than simply as text, and cards were introduced to help better group different types of content (e.g. a table of Replication Controllers and a table of Pods on your “Workloads” page). Material’s guidelines around desktop-focused enterprise-level software are currently limited (and instead focus on a mobile-first context), so we’ve had to improvise with some aspects of the UI and have worked closely with the UX team at Google Cloud Platform to do this – drawing on their expertise in implementing Material in a more information-dense setting.Sample Use CaseTo showcase Dashboard 1.4’s new suite of features and how they’ll make users’ lives better in the real world, let’s imagine the following scenario:I am a cluster operator and a customer pings me warning that their app, Kubernetes Dashboard, is suffering performance issues. My first step in addressing the issue is to switch to the correct Namespace, kube-system, to examine what could be going on. Once in the relevant Namespace, I check out my Deployments to see if anything seems awry. Sure enough, I notice a spike in CPU usage. I realize we need to perform a rolling update to a newer version of that app that can handle the increased requests it’s evidently getting, so I update this Deployment’s image, which in turn creates a new Replica Set. Now that that Replica Set’s been created, I can open the logs for one of its pods to confirm that it’s been successfully connected to the API server. Easy as that, we’ve debugged our issue. Dashboard provided us a centralized location to scan for the origin of the problem, and once we had that identified we were able to drill down and address the root of the problem.Why the Skipped Versions?If you’ve been following along with Dashboard since 1.0, you may have been confused by the jump in our versioning; we went 1.0, 1.1…1.4. We did this to synchronize with the main Kubernetes distro, and hopefully going forward this will make that relationship easier to understand.There’s a Lot More Where That Came FromDashboard is gaining momentum, and these early stages are a very exciting and rewarding time to be involved. If you’d like to learn more about contributing, check out #SIG UI. Chat with us Kubernetes Slack: sig-ui channel.–Dan Romlein, UX designer, ApprendaDownload KubernetesGet involved with the Kubernetes project on GitHub Post questions (or answer questions) on Stack Overflow Connect with the community on SlackFollow us on Twitter @Kubernetesio for latest updates
Quelle: kubernetes

4. Oktober 20164. Oktober 2016

da Agency

How we improved Kubernetes Dashboard UI in 1.4 for your production needs

4. Oktober 20164. Oktober 2016

da Agency

Your Docker agenda for the month of October

From webinars to workshops, meetups to conference talks, check out our list of events that are coming up in October!

Online
Oct 13: Docker for Windows Server 2016 by Michael Friis
Oct 18: Docker Datacenter Demo by Moni Sallama and Chris Hines.

Official Docker Training Course
View the full schedule of instructor led training courses here!
Introduction to Docker: This is a two-day, on-site or classroom-based training course which introduces you to the Docker platform and takes you through installing, integrating, and running it in your working environment.
Oct 11-12: Introduction to Docker with Xebia – Paris, France
Oct 19-20: Introduction to Docker with Contino &8211; London, United Kingdom
Oct 24-25: Introduction to Docker with AKRA &8211; Krakow, Germany

Docker Administration and Operations: The Docker Administration and Operations course consists of both the Introduction to Docker course, followed by the Advanced Docker Topics course, held over four consecutive days.
Oct 3-6: Docker Administration and Operations with Azca &8211; Madrid, Spain
Oct 11-15: Docker Administration and Operations with TREEPTIK &8211; Paris, France
Oct 18-21: Docker Administration and Operations with Vizuri &8211; Raleigh, NC
Oct 18-22: Docker Administration and Operations with TREEPTIK &8211; Aix en Provence, France
Oct 24-27: Docker Administration and Operations with AKRA &8211; Krakow, Germany
Oct 31- Nov 3: Docker Administration and Operations by Luis Herrera, Docker Captain &8211; Lisboa, Portugal

Advanced Docker Operations: This two day course is designed to help new and experienced systems administrators learn to use Docker to control the Docker daemon, security, Docker Machine, Swarm, and Compose.
Oct 10-11 Advanced Docker Operations with Ben Wootton, Docker Captain &8211; London, UK
Oct 26-27: Advanced Docker Operations with AKRA &8211; Krakow, Poland

North America & Latin America
Oct 5th: DOCKER MEETUP AT MELTMEDIA &8211; Tempe, AZ
The speaker, @leodotcloud, will discuss the background, present ecosystem of the Container Network Interface (CNI) for containers.
Oct 6th: DOCKER MEETUP AT RACKSPACE &8211; Austin, TX
Jeff Lindsay will give a preview talk to container days where he will cover what the different components of a cluster manager are and what are things you should pay attention to if you really wanted to build your own cluster management solution.
Oct 11th: DOCKER MEETUP AT REPLICATED &8211; Los Angeles, CA
Marc Campbell will share some best practices of using Docker in production, starting with using Content Trust and signed images (including the internals of how Content Trust is built), and then discussing a Continuous Integration/Delivery workflow that can reliably and securely deliver and run Docker containers in any environment.
Oct 12th: DOCKER MEETUP IN BATON ROUGE &8211; Baton Rouge, LA
This Docker meetup will be hosted by Brandon Willmott of the local VMware User Group.
Oct 12th: DOCKER MEETUP AT TUNE &8211; Seattle, WA
Join this meetup to hear talks from Nick Thompson from TUNE, Avi Cavali from Shippable and DJ Enriquez from OpenMail. Also Wes McNamee, a winner of the Docker 1.12 Hackathon, will also be presenting his project Swarm-CI. This is not to be missed!
Oct 13th: DOCKER MEETUP AT CAPITAL ALE HOUSE &8211; Richmond, VA
Scott Cochran, Master Software Engineer at Capital One, will be talking about his journey in adopting docker containers to solve business problems and the things he learned along the way.
Oct 17th: DOCKER MEETUP AT BRAINTREE &8211; Chicago, IL
Tsvi Korren, director of technical services at Aqua, is going to present a talk entitled ‘Docker Container Application Security Deep Dive’ where he will discuss how to integrate compliance and security checks into your pipeline and how to produce a secure, verifiable image.
Oct 18th: DOCKER MEETUP AT THE INNEVATION CENTER &8211; Las Vegas, NV
Using the Docker volume plug-in with external container storage allows data to be persisted, allows per-container volume management and high-availability for stateful apps. Join this informative meetup with Gou Rao, CTO and co-founder of Portworx, where we’ll discuss: Best practices for managing stateful containerized applications.
Oct 18th: DOCKER MEETUP AT WILDBIT &8211; PHILADELPHIA, PA
Ben Grissinger, Solutions Engineer at Docker, will discuss Docker Swarm! He will cover the requirements for using swarm mode and take a peak at what we can expect in the near future from Docker regarding swarm mode. Last but not he will be doing a demo using swarm mode and using a visualizer tool to display what is taking place in the swarm cluster during the demo of swarm mode in action.
Oct 18th: DOCKER MEETUP AT SANTANDER &8211; Sao Paulo, Brazil
Join Docker São Paulo for their 8th meetup. Get in touch if you would like to submit a talk.
Oct 29th: DOCKER MEETUP AT CI&T &8211; Campinas, Brazil
Save the date for the first Docker Campinas meetup. More details to follow soon.

Europe
Oct 4th: LINUXCON EUROPE / CONTAINERCON EU &8211; Berlin, Germany
We had such a great time attending and speaking at LinuxCon and ContainerCon North America, that we are doing it again next week in Berlin – only bigger and better this time! Make sure to come visit us at booth #D38 and check out the awesome Docker sessions we have lined up.
Oct 4th: THE INCREDIBLE AUTOMATION DAY (TIAD) PARIS &8211; Paris, France
Roberto Hashioka from Docker will share how to build a powerful real-time data processing pipeline & visualization solution using Docker Machine and Compose, Kafka, Cassandra and Spark in 5 steps.
Oct 4th: DOCKER MEETUP IN COPENHAGEN &8211; Copenhagen, Denmark
Learn to be a DevOps &8211; workshop for beginners.
Oct 5th: WEERT SOFTWARE DEVELOPMENT MEETUP &8211; Weert, Netherlands
Kabisa will host a Docker workshop. The workshop is intended for people who are interested in Docker. Last year you have heard and read a lot about Docker. “Our workshop is a next step for you to gain some hands-on experience.”
Oct 6th: DOCKER MEETUP AT ZANOX &8211; Berlin, Germany
Patrick Chanezon: What&8217;s new with Docker, covering Docker announcements from the past 6 months, with a demo of the latest and greatest Docker products for dev and ops.
Oct 6th: TECH UNPLUGGED &8211; Amsterdam, The Netherlands
Docker Captain Nigel Poulton is presenting on container security at @techunplugged in Amsterdam.
Oct 11th: DOCKER MEETUP AT MONDAY CONSULTING GMBH &8211; Hamburg, Germany
Tom Hutter prepared some material about: aliases and bash-completion, Dockerfile, docker-compose, bind mount: access folders outside build root, supervisord, firewalls (iptables), housekeeping.
Oct 11th: London Dev Community Meetup &8211; London, United Kingdom
Building Microservices with Docker.
Oct 12th: GOTO &8211; LONDON &8211; London, United Kingdom
GOTO London will give you the opportunity to talk with people across all different disciplines of software development! Join Docker captain Adrian Mouat talk about Docker.
Oct 13th: DOCKER MEETUP AT YNOV BORDEAUX &8211; Bordeaux, France
David Gageot from Docker will be presenting.
Oct 15th: DOCKER MEETUP AT BKM &8211; Istanbul, Turkey
Event will be handled by Derya SEZEN and Huseyin BABAL and there will be cool topics about Docker with real life best practices and also we have some challenges for you. Do not forget to bring your laptops with you.
Oct 15th: DOCKER MEETUP AT BUCHAREST TECH HUB &8211; Bucharest, Romania
Welcome to the second workshop of the free Docker 101 Workshop Meetups!
This is going to be a 5h+ Workshop, so be prepared! This workshop is an introduction in the world of Docker containers. It provides an overview about what exactly is Docker and how can it benefit both developers looking to build applications quickly and IT team looking to manage the IT environment.
Oct 17th: OSCON LONDON &8211; London, UK
Hear the latest about the Docker project from Patrick Chanezon.
Oct 18th: DOCKER MEETUP AT TRADESHIFT &8211; Denmark, Copenhagen
We are going to talk about Continuous Integration, Continuous Deployment. Why is that important, why should you care? CI/CD as it is abbreviated is not only about the technical, it is also about how you can improve your team with new tools that help you deliver features faster with fewer errors.
Oct 18th: DOCKER MEETUP AT HORTONWORKS BUDAPEST &8211; Budapest, Hungary
This Meetup will focus on the new features of Docker 1.12.
Oct 26th: DOCKER MEETUP AT DIE MOBILIAR &8211; Zürich, Switzerland
We are happy to announce the 11th Docker Switzerland meetup. Talks include an introduction into swarmkit by Michael Müller from Container Solutions.
Oct 26th: DOCKER MEETUP AT BENTOXBOX &8211; Verona, Italy
Join us for our first meetup! Docker Captain Lorenzo Fontana, DevOps Expert at Kiratech, will be joining us!

APAC
Oct 18th: DOCKER MEETUP AT DIMENSION DATA &8211; Sydney, Australia
“Docker inside out, reverse engineering Docker” By Anthony Shaw, “Group Director, Innovation and Technical Development” at Dimension Data. Summary: In this talk Anthony will be explaining how Docker works by reverse engineering the core concepts and illustrating the technology by building a Docker clone live during the talk.
Oct 18th: DOCKER MEETUP IN MELBOURNE &8211; Melbourne, Australia
Continuous Integration & Deployment for Docker Workloads on Azure Container Services. Presenter: Ken Thompson (OSS TSP, Microsoft).
Oct 18th: DOCKER MEETUP IN SINGAPORE &8211; Singapore, Singapore
Docker for AWS (Vincent de Smet) with a demo on using docker machine with a remote host by Sergey Shishkin.
Oct 22nd: DOCKER CLUSTERING WITH TECH NEXT MEETUP &8211; Pune, India
Dockerize a multi-container data crunching app.

The post Your Docker agenda for the month of October appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

2. Oktober 20162. Oktober 2016

da Agency

Your Guide to LinuxCon and ContainerCon Europe

Hey Dockers! We had such a great time attending and speaking at #LinuxCon and #ContainerCon North America, that we are doing it again next week in Berlin – only bigger and better this time! Make sure to come visit us at booth #D38 and check out the awesome Docker sessions we have lined up:
Keynote!
Solomon Hykes, Docker’s Founder and CTO, will kick off LinuxCon with the first keynote at 9:25. If you aren’t joining us in Berlin, you can live stream his and the other keynotes by registering here.
Sessions
Tuesday October 4th:
11:15 &8211; 12:05 Docker Captain Adrian Mouat will deliver a comparison of orchestration tools including Docker Swarm, Mesos/Marathon and Kubernetes.

12:15 &8211; 1:05 Patrick Chanezon and David Chung from Docker’s technical team along with Docker Captain and maintainer Phil Estes will demonstrate how to build distributed systems without Docker, using Docker plumbing projects, including RunC, containerd, swarmkit, hyperkit, vpnkit, datakit.

2:30 &8211; 3:20 Docker’s Mike Goelzer will introduce the audience to Docker Services in Getting Started with Docker Services, explain what they are and how to use them to deploy multi-tier applications. Mike will also cover load balancing, service discovery, scaling, security, deployment models, and common network topologies.

3:30 &8211; 4:20 Stephen Day, Docker Technical Staff, will introduce SwarmKit: Docker’s Simplified Model for Complex Orchestration. Stephen will dive into the model driven design and demonstrate how the components fit together to build a user-friendly orchestration system designed to handle modern applications.

3:30 &8211; 4:20 Docker’s Paul Novarese will dive into User namespace and Seccomp support in Docker Engine, covering new features that respectively allow users to run Containers without elevated privileges and provide different containment methods.

3:30 &8211; 4:20 Docker Captain Laura Frank will show how to use Docker Engine, Registry and Compose to quickly and efficiently test software in her session: Building Efficient Parallel Testing Platforms with Docker.

Wednesday October 5th:
2:30 &8211; 3:20 Docker Captain Phil Estes goes into details on why companies are choosing to use containers because of their security &8211; not in spite of it. In How Secure is your Container? A Docker Engine Security Update, Phil will demonstrate recent additions to the Docker engine in 2016 such as user namespaces and seccomp and how they continue to enable better container security and isolation.

3:40 &8211; 4:30 Aaron Lehmann, Docker Technical Staff, will cover Docker Orchestration: Beyond the Basics and discuss best practices for running a cluster using Docker Engine&8217;s orchestration features &8211; from getting started to keeping a cluster perfomant, secure, and reliable.

4:40 &8211; 5:30 Docker’s Riyaz Faizullabhoy and Lily Guo will deliver When The Going Gets Tough, Get TUF Going! The Update Framework (TUF) helps developers secure new or existing software update systems. In this session, you will learn the attacks that TUF protects against and how it actually does so in a usable manner.

Thursday October 6th:
10:50 &8211; 11:40 Docker Technical Staff Drew Erny will explain the mechanisms used in the core Docker Engine orchestration platform to tolerate failures of services and machines, from cluster state replication and leader-election to container re-scheduling logic when a host goes down in his session Orchestrating Linux Containers while Tolerating Failures.
11:50 &8211; 12:40 Docker’s Amir Chaudhry will explain Unikernels: When you Should and When you Shouldn’t to help you weigh the pros and cons of using unikernels and help you decide when when it may be appropriate to consider a library OS for your next project.
18:45: Docker Berlin meetup: Patrick Chanezon: What&8217;s new with Docker, covering Docker announcements from the past 6 months, with a demo of the latest and greatest Docker products for dev and ops.
Friday October 7th:
9:00am – 12:00 pm Docker Captain Neependra Khare will lead a Tutorial on Comparing Container Orchestration Tools.
1:00 pm – 5:00 pm In this 3 hour tutorial, Jerome Petazzoni will teach attendees how to Orchestrate Containers in Production at Scale with Docker Swarm.

In addition to our Docker talks, we have an amazing Docker Berlin meetup lined up just for you on Thursday October 6th. The meetup kicks off with Patrick Chanezon, a member of technical staff at Docker, will cover Docker announcements from the past 6 months and demo the latest and greatest Docker products for dev and ops. Then, Paul J. Adams, Engineering Manager at Crate.io, will demonstrate how easy it is to setup and manage a Crate database cluster using Docker Engine and Swarm Mode.
[Tweet “We&8217;re excited to be at LinuxCon + ContainerCon next week in Berlin! Here&8217;s our guide to the best sessions”]
CLICK TO TWEET

The post Your Guide to LinuxCon and ContainerCon Europe appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/