Kategorie: Kubernetes

PaddlePaddle Fluid: Elastic Deep Learning on Kubernetes

Editor’s note: Today’s post is a joint post from the deep learning team at Baidu and the etcd team at CoreOS.PaddlePaddle Fluid: Elastic Deep Learning on KubernetesTwo open source communities—PaddlePaddle, the deep learning framework originated in Baidu, and Kubernetes®, the most famous containerized application scheduler—are announcing the Elastic Deep Learning (EDL) feature in PaddlePaddle’s new release codenamed Fluid.Fluid EDL includes a Kubernetes controller, PaddlePaddle auto-scaler, which changes the number of processes of distributed jobs according to the idle hardware resource in the cluster, and a new fault-tolerable architecture as described in the PaddlePaddle design doc.Industrial deep learning requires significant computation power. Research labs and companies often build GPU clusters managed by SLURM, MPI, or SGE. These clusters either run a submitted job if it requires less than the idle resource, or pend the job for an unpredictably long time. This approach has its drawbacks: in an example with 99 available nodes and a submitted job that requires 100, the job has to wait without using any of the available nodes. Fluid works with Kubernetes to power elastic deep learning jobs, which often lack optimal resources, by helping to expose potential algorithmic problems as early as possible.Another challenge is that industrial users tend to run deep learning jobs as a subset stage of the complete data pipeline, including the web server and log collector. Such general-purpose clusters require priority-based elastic scheduling. This makes it possible to run more processes in the web server job and less in deep learning during periods of high web traffic, then prioritize deep learning when web traffic is low. Fluid talks to Kubernetes’ API server to understand the global picture and orchestrate the number of processes affiliated with various jobs.In both scenarios, PaddlePaddle jobs are tolerant to a process spikes and decreases. We achieved this by implementing the new design, which introduces a master process in addition to the old PaddlePaddle architecture as described in a previous blog post. In the new design, as long as there are three processes left in a job, it continues. In extreme cases where all processes are killed, the job can be restored and resume.We tested Fluid EDL for two use cases: 1) the Kubernetes cluster runs only PaddlePaddle jobs; and 2) the cluster runs PaddlePaddle and Nginx jobs.In the first test, we started up to 20 PaddlePaddle jobs one by one with a 10-second interval. Each job has 60 trainers and 10 parameter server processes, and will last for hours. We repeated the experiment 20 times: 10 with FluidEDL turned off and 10 with FluidEDL turned on. In Figure one, solid lines correspond to the first 10 experiments and dotted lines the rest. In the upper part of the figure, we see that the number of pending jobs increments monotonically without EDL. However, when EDL is turned on, resources are evenly distributed to all jobs. Fluid EDL kills some existing processes to make room for new jobs and jobs coming in at a later point in time. In both cases, the cluster is equally utilized (see lower part of figure).Figure 1. Fluid EDL evenly distributes resource among jobs.In the second test, each experiment ran 400 Nginx pods, which has higher priority than the six PaddlePaddle jobs. Initially, each PaddlePaddle job had 15 trainers and 10 parameter servers. We killed 100 Nginx pods every 90 seconds until 100 left, and then we started to increase the number of Nginx jobs by 100 every 90 seconds. The upper part of Figure 2 shows this process. The middle of the diagram shows that Fluid EDL automatically started some PaddlePaddle processes by decreasing Nginx pods, and killed PaddlePaddle processes by increasing Nginx pods later on. As a result, the cluster maintains around 90% utilization as shown in the bottom of the figure. When Fluid EDL was turned off, there were no PaddlePaddle processes autoincrement, and the utilization fluctuated with the varying number of Nginx pods.Figure 2. Fluid changes PaddlePaddle processes with the change of Nginx processes.We continue to work on FluidEDL and welcome comments and contributions. Visit the PaddlePaddle repo, where you can find the design doc, a simple tutorial, and experiment details.Xu Yan (Baidu Research)Helin Wang (Baidu Research)Yi Wu (Baidu Research)Xi Chen (Baidu Research)Weibao Gong (Baidu Research)Xiang Li (CoreOS)- Yi Wang (Baidu Research)
Quelle: kubernetes

Using eBPF in Kubernetes

IntroductionKubernetes provides a high-level API and a set of components that hides almost all of the intricate and—to some of us—interesting details of what happens at the systems level. Application developers are not required to have knowledge of the machines’ IP tables, cgroups, namespaces, seccomp, or, nowadays, even the container runtime that their application runs on top of. But underneath, Kubernetes and the technologies upon which it relies (for example, the container runtime) heavily leverage core Linux functionalities.This article focuses on a core Linux functionality increasingly used in networking, security and auditing, and tracing and monitoring tools. This functionality is called extended Berkeley Packet Filter (eBPF)Note: In this article we use both acronyms: eBPF and BPF. The former is used for the extended BPF functionality, and the latter for “classic” BPF functionality. What is BPF?BPF is a mini-VM residing in the Linux kernel that runs BPF programs. Before running, BPF programs are loaded with the bpf() syscall and are validated for safety: checking for loops, code size, etc. BPF programs are attached to kernel objects and executed when events happen on those objects—for example, when a network interface emits a packet.BPF SuperpowersBPF programs are event-driven by definition, an incredibly powerful concept, and executes code in the kernel when an event occurs. Netflix’s Brendan Gregg refers to BPF as a Linux superpower.The ‘e’ in eBPFTraditionally, BPF could only be attached to sockets for socket filtering. BPF’s first use case was in `tcpdump`. When you run `tcpdump` the filter is compiled into a BPF program and attached to a raw `AF_PACKET` socket in order to print out filtered packets.But over the years, eBPF added the ability to attach to other kernel objects. In addition to socket filtering, some supported attach points are:Kprobes (and userspace equivalents uprobes)TracepointsNetwork schedulers or qdiscs for classification or action (tc)XDP (eXpress Data Path)This and other, newer features like in-kernel helper functions and shared data-structures (maps) that can be used to communicate with user space, extend BPF’s capabilities.Existing Use Cases of eBPF with KubernetesSeveral open-source Kubernetes tools already use eBPF and many use cases warrant a closer look, especially in areas such as networking, monitoring and security tools.Dynamic Network Control and Visibility with CiliumCilium is a networking project that makes heavy use of eBPF superpowers to route and filter network traffic for container-based systems. By using eBPF, Cilium can dynamically generate and apply rules—even at the device level with XDP—without making changes to the Linux kernel itself.The Cilium Agent runs on each host. Instead of managing IP tables, it translates network policy definitions to BPF programs that are loaded into the kernel and attached to a container’s virtual ethernet device. These programs are executed—rules applied—on each packet that is sent or received.This diagram shows how the Cilium project works:Depending on what network rules are applied, BPF programs may be attached with tc or XDP. By using XDP, Cilium can attach the BPF programs at the lowest possible point, which is also the most performant point in the networking software stack.If you’d like to learn more about how Cilium uses eBPF, take a look at the project’s BPF and XDP reference guide.Tracking TCP Connections in Weave ScopeWeave Scope is a tool for monitoring, visualizing and interacting with container-based systems. For our purposes, we’ll focus on how Weave Scope gets the TCP connections.Weave Scope employs an agent that runs on each node of a cluster. The agent monitors the system, generates a report and sends it to the app server. The app server compiles the reports it receives and presents the results in the Weave Scope UI.To accurately draw connections between containers, the agent attaches a BPF program to kprobes that track socket events: opening and closing connections. The BPF program, tcptracer-bpf, is compiled into an ELF object file and loaded using gopbf.(As a side note, Weave Scope also has a plugin that make use of eBPF: HTTP statistics.)To learn more about how this works and why it’s done this way, read this extensive post that the Kinvolk team wrote for the Weaveworks Blog. You can also watch a recent talk about the topic.Limiting syscalls with seccomp-bpfLinux has more than 300 system calls (read, write, open, close, etc.) available for use—or misuse. Most applications only need a small subset of syscalls to function properly. seccomp is a Linux security facility used to limit the set of syscalls that an application can use, thereby limiting potential misuse.The original implementation of seccomp was highly restrictive. Once applied, if an application attempted to do anything beyond reading and writing to files it had already opened, seccomp sent a `SIGKILL` signal.seccomp-bpf enables more complex filters and a wider range of actions. Seccomp-bpf, also known as seccomp mode 2, allows for applying custom filters in the form of BPF programs. When the BPF program is loaded, the filter is applied to each syscall and the appropriate action is taken (Allow, Kill, Trap, etc.).seccomp-bpf is widely used in Kubernetes tools and exposed in Kubernetes itself. For example, seccomp-bpf is used in Docker to apply custom seccomp security profiles, in rkt to apply seccomp isolators, and in Kubernetes itself in its Security Context.But in all of these cases the use of BPF is hidden behind libseccomp. Behind the scenes, libseccomp generates BPF code from rules provided to it. Once generated, the BPF program is loaded and the rules applied.Potential Use Cases for eBPF with KuberneteseBPF is a relatively new Linux technology. As such, there are many uses that remain unexplored. eBPF itself is also evolving: new features are being added in eBPF that will enable new use cases that aren’t currently possible. In the following sections, we’re going to look at some of these that have only recently become possible and ones on the horizon. Our hope is that these features will be leveraged by open source tooling.Pod and container level network statisticsBPF socket filtering is nothing new, but BPF socket filtering per cgroup is. Introduced in Linux 4.10, cgroup-bpf allows attaching eBPF programs to cgroups. Once attached, the program is executed for all packets entering or exiting any process in the cgroup.A cgroup is, amongst other things, a hierarchical grouping of processes. In Kubernetes, this grouping is found at the container level. One idea for making use of cgroup-bpf, is to install BPF programs that collect detailed per-pod and/or per-container network statistics.Generally, such statistics are collected by periodically checking the relevant file in Linux’s `/sys` directory or using Netlink. By using BPF programs attached to cgroups for this, we can get much more detailed statistics: for example, how many packets/bytes on tcp port 443, or how many packets/bytes from IP 10.2.3.4. In general, because BPF programs have a kernel context, they can safely and efficiently deliver more detailed information to user space.To explore the idea, the Kinvolk team implemented a proof-of-concept: https://github.com/kinvolk/cgnet. This project attaches a BPF program to each cgroup and exports the information to Prometheus.There are of course other interesting possibilities, like doing actual packet filtering. But the obstacle currently standing in the way of this is having cgroup v2 support—required by cgroup-bpf—in Docker and Kubernetes.Application-applied LSMLinux Security Modules (LSM) implements a generic framework for security policies in the Linux kernel. SELinux and AppArmor are examples of these. Both of these implement rules at a system-global scope, placing the onus on the administrator to configure the security policies.Landlock is another LSM under development that would co-exist with SELinux and AppArmor. An initial patchset has been submitted to the Linux kernel and is in an early stage of development. The main difference with other LSMs is that Landlock is designed to allow unprivileged applications to build their own sandbox, effectively restricting themselves instead of using a global configuration. With Landlock, an application can load a BPF program and have it executed when the process performs a specific action. For example, when the application opens a file with the open() system call, the kernel will execute the BPF program, and, depending on what the BPF program returns, the action will be accepted or denied.In some ways, it is similar to seccomp-bpf: using a BPF program, seccomp-bpf allows unprivileged processes to restrict what system calls they can perform. Landlock will be more powerful and provide more flexibility. Consider the following system call:Cfd = open(“myfile.txt”, O_RDWR);The first argument is a “char *”, a pointer to a memory address, such as `0xab004718`. With seccomp, a BPF program only has access to the parameters of the syscall but cannot dereference the pointers, making it impossible to make security decisions based on a file. seccomp also uses classic BPF, meaning it cannot make use of eBPF maps, the mechanism for interfacing with user space. This restriction means security policies cannot be changed in seccomp-bpf based on a configuration in an eBPF map.BPF programs with Landlock don’t receive the arguments of the syscalls but a reference to a kernel object. In the example above, this means it will have a reference to the file, so it does not need to dereference a pointer, consider relative paths, or perform chroots.Use Case: Landlock in Kubernetes-based serverless frameworksIn Kubernetes, the unit of deployment is a pod. Pods and containers are the main unit of isolation. In serverless frameworks, however, the main unit of deployment is a function. Ideally, the unit of deployment equals the unit of isolation. This puts serverless frameworks like Kubeless or OpenFaaS into a predicament: optimize for unit of isolation or deployment?To achieve the best possible isolation, each function call would have to happen in its own container—ut what’s good for isolation is not always good for performance. Inversely, if we run function calls within the same container, we increase the likelihood of collisions.By using Landlock, we could isolate function calls from each other within the same container, making a temporary file created by one function call inaccessible to the next function call, for example. Integration between Landlock and technologies like Kubernetes-based serverless frameworks would be a ripe area for further exploration.Auditing kubectl-exec with eBPFIn Kubernetes 1.7 the audit proposal started making its way in. It’s currently pre-stable with plans to be stable in the 1.10 release. As the name implies, it allows administrators to log and audit events that take place in a Kubernetes cluster. While these events log Kubernetes events, they don’t currently provide the level of visibility that some may require. For example, while we can see that someone has used `kubectl exec` to enter a container, we are not able to see what commands were executed in that session. With eBPF one can attach a BPF program that would record any commands executed in the `kubectl exec` session and pass those commands to a user-space program that logs those events. We could then play that session back and know the exact sequence of events that took place.Learn more about eBPFIf you’re interested in learning more about eBPF, here are some resources:A comprehensive reading list about eBPF for doing just thatBCC (BPF Compiler Collection) provides tools for working with eBPF as well as many example tools making use of BCC.Some videosBPF: Tracing and More by Brendan GreggCilium – Container Security and Networking Using BPF and XDP by Thomas GrafUsing BPF in Kubernetes by Alban CrequyConclusionWe are just starting to see the Linux superpowers of eBPF being put to use in Kubernetes tools and technologies. We will undoubtedly see increased use of eBPF. What we have highlighted here is just a taste of what you might expect in the future. What will be really exciting is seeing how these technologies will be used in ways that we have not yet thought about. Stay tuned!The Kinvolk team will be hanging out at the Kinvolk booth at KubeCon in Austin. Come by to talk to us about all things, Kubernetes, Linux, container runtimes and yeah, eBPF.
Quelle: kubernetes

Top 5 blogs of 2017: LinuxKit, A Toolkit for building Secure, Lean and Portable Linux Subsystems

In case you’ve missed it, this week we’re highlighting the top five most popular Docker blogs in 2017. Coming in the third place is the announcement of LinuxKit, a toolkit for building secure, lean and portable Linux Subsystems.

 
LinuxKit includes the tooling to allow building custom Linux subsystems that only include exactly the components the runtime platform requires. All system services are containers that can be replaced, and everything that is not required can be removed. All components can be substituted with ones that match specific needs. It is a kit, very much in the Docker philosophy of batteries included but swappable. LinuxKit is an open source project available at https://github.com/linuxkit/linuxkit.
To achieve our goals of a secure, lean and portable OS,we built it from containers, for containers.  Security is a top-level objective and aligns with NIST stating, in their draft Application Container Security Guide: “Use container-specific OSes instead of general-purpose ones to reduce attack surfaces. When using a container-specific OS, attack surfaces are typically much smaller than they would be with a general-purpose OS, so there are fewer opportunities to attack and compromise a container-specific OS.”
The leanness directly helps with security by removing parts not needed if the OS is designed around the single use case of running containers. Because LinuxKit is container-native, it has a very minimal size – 35MB with a very minimal boot time.  All system services are containers, which means that everything can be removed or replaced.
System services are sandboxed in containers, with only the privileges they need. The configuration is designed for the container use case. The whole system is built to be used as immutable infrastructure, so it can be built and tested in your CI pipeline, deployed, and new versions are redeployed when you wish to upgrade.
The kernel comes from our collaboration with the Linux kernel community, participating in the process and work with groups such as the Kernel Self Protection Project (KSPP), while shipping recent kernels with only the minimal patches needed to fix issues with the platforms LinuxKit supports. The kernel security process is too big for a single company to try to develop on their own therefore a broad industry collaboration is necessary.
In addition LinuxKit provides a space to incubate security projects that show promise for improving Linux security. We are working with external open source projects such as Wireguard, Landlock, Mirage, oKernel, Clear Containers and more to provide a testbed and focus for innovation in the container space, and a route to production.
LinuxKit is portable, as it was built for the many platforms Docker runs on now, and with a view to making it run on far more.. Whether they are large or small machines, bare metal or virtualized, mainframes or the kind of devices that are used in Internet of Things scenarios as containers reach into every area of computing.
Learn More about Linuxkit:

Check out the LinuxKit repository on GitHub
Watch the LinuxKit video from the last Moby Summit to learn more about the latest features, updates and use cases from the community
Read the Announcement

#LinuxKit: A Toolkit for building Secure, Lean and Portable Linux SubsystemsClick To Tweet

The post Top 5 blogs of 2017: LinuxKit, A Toolkit for building Secure, Lean and Portable Linux Subsystems appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Top 5 blogs of 2017: Spring Boot Development with Docker

We’ve rounded up the top five most popular Docker blogs of 2017. Coming in at number four is, Spring Boot Development With Docker, part of a multi-part tutorial series.

The AtSea Shop is an example storefront application that can be deployed on different operating systems and can be customized to both your enterprise development and operational environments. In my last post, I discussed the architecture of the app. In this post, I will cover how to setup your development environment to debug the Java REST backend that runs in a container.
Building the REST Application
I used the Spring Boot framework to rapidly develop the REST backend that manages products, customers and orders tables used in the AtSea Shop. The application takes advantage of Spring Boot’s built-in application server, support for REST interfaces and ability to define multiple data sources. Because it was written in Java, it is agnostic to the base operating system and runs in either Windows or Linux containers. This allows developers to build against a heterogenous architecture.
Project setup
The AtSea project uses multi-stage builds, a new Docker feature, which allows me to use multiple images to build a single Docker image that includes all the components needed for the application. The multi-stage build uses a Maven container to build the the application jar file. The jar file is then copied to a Java Development Kit image. This makes for a more compact and efficient image because the Maven is not included with the application. Similarly, the React store front client is built in a Node image and the compile application is also added to the final application image.
I used Eclipse to write the AtSea app. If you want info on configuring IntelliJ or Netbeans for remote debugging, you can check out the the Docker Labs Repository. You can also check out the code in the AtSea app github repository.
I built the application by cloning the repository and imported the project into Eclipse by setting the Root Directory to the project and clicking Finish
    File > Import > Maven > Existing Maven Projects 
Since I used using Spring Boot, I took advantage of spring-devtools to do remote debugging in the application. I had to add the Spring Boot-devtools dependency to the pom.xml file.
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-devtools</artifactId>
</dependency>
Note that developer tools are automatically disabled when the application is fully packaged as a jar. To ensure that devtools are available during development, I set the <excludeDevtools> configuration to false in the spring-boot-maven build plugin:
<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <configuration>
                <excludeDevtools>false</excludeDevtools>
            </configuration>
        </plugin>
    </plugins>
</build>
This example uses a Docker Compose file that creates a simplified build of the containers specifically needed for development and debugging.
 version: “3.1”

services:
 database:
   build: 
      context: ./database
   image: atsea_db
   environment:
     POSTGRES_USER: gordonuser
     POSTGRES_DB: atsea
   ports:
     – “5432:5432″ 
   networks:
     – back-tier
   secrets:
     – postgres_password

 appserver:
   build:
      context: .
      dockerfile: app/Dockerfile-dev
   image: atsea_app
   ports:
     – “8080:8080″
     – “5005:5005″
   networks:
     – front-tier
     – back-tier
   secrets:
     – postgres_password

secrets:
 postgres_password:
   file: ./devsecrets/postgres_password
   
networks:
 front-tier:
 back-tier:
 payment:
   driver: overlay
 The Compose file uses secrets to provision passwords and other sensitive information such as certificates –  without relying on environmental variables. Although the example uses PostgreSQL, the application can use secrets to connect to any database defined by as a Spring Boot datasource. From JpaConfiguration.java:
 public DataSourceProperties dataSourceProperties() {
        DataSourceProperties dataSourceProperties = new DataSourceProperties();

    // Set password to connect to database using Docker secrets.
    try(BufferedReader br = new BufferedReader(new FileReader(“/run/secrets/postgres_password”))) {
        StringBuilder sb = new StringBuilder();
        String line = br.readLine();
        while (line != null) {
            sb.append(line);
            sb.append(System.lineSeparator());
            line = br.readLine();
        }
         dataSourceProperties.setDataPassword(sb.toString());
     } catch (IOException e) {
        System.err.println(“Could not successfully load DB password file”);
     }
    return dataSourceProperties;
}
Also note that the appserver opens port 5005 for remote debugging and that build calls the Dockerfile-dev file to build a container that has remote debugging turned on. This is set in the Entrypoint which specifies transport and address for the debugger.
ENTRYPOINT [“java”, 

“-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005″,”-jar”, 

“/app/AtSea-0.0.1-SNAPSHOT.jar”]
Remote Debugging
To start remote debugging on the application, run compose using the docker-compose-dev.yml file.
docker-compose -f docker-compose-dev.yml up –build
Docker will build the images and start the AtSea Shop database and appserver containers. However, the application will not fully load until Eclipse’s remote debugger attaches to the application. To start remote debugging you click on Run > Debug Configurations …
Select Remote Java Application then press the new button to create a configuration. In the Debug Configurations panel, you give the configuration a name, select the AtSea project and set the connection properties for host and the port to 5005. Click Apply > Debug.  

The appserver will start up.
appserver_1|2017-05-09 03:22:23.095 INFO 1 — [main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http)

appserver_1|2017-05-09 03:22:23.118 INFO 1 — [main] com.docker.atsea.AtSeaApp                : Started AtSeaApp in 38.923 seconds (JVM running for 109.984)
To test remote debugging set a breakpoint on ProductController.java where it returns a list of products.

You can test it using curl or your preferred tool for making HTTP requests:
curl -H “Content-Type: application/json” -X GET  http://localhost:8080/api/product/
Eclipse will switch to the debug perspective where you can step through the code.

The AtSea Shop example shows how easy it is to use containers as part of your normal development environment using tools that you and your team are familiar with. Download the application to try out developing with containers or use it as basis for your own Spring Boot REST application.
Interested in more? Check out these developer resources and videos from Dockercon 2017.

AtSea Shop demo
Docker Reference Architecture: Development Pipeline Best Practices Using Docker EE
Docker Labs

Developer Tools
Java development using docker

DockerCon videos

Docker for Java Developers
The Rise of Cloud Development with Docker & Eclipse Che
All the New Goodness of Docker Compose
Docker for Devs

Top 5 blogs of 2017: Developing the AtSea app with #Docker and #SpringBoot by @sparaClick To Tweet

The post Top 5 blogs of 2017: Spring Boot Development with Docker appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Top 5 Blogs of 2017: Docker Platform and Moby Project add Kubernetes

As we count down the final days of 2017, we would like to bring you the final installment of the top 5 blogs of 2017. On day 5, we take a look back DockerCon EU, when we announced Kubernetes support in the Docker platform. This blog takes an in-depth look at the industry-leading container platform and the addition of Kubernetes.

The Docker platform is integrating support for Kubernetes so that Docker customers and developers have the option to use both Kubernetes and Swarm to orchestrate container workloads. Register for beta access and check out the detailed blog posts to learn how we’re bringing Kubernetes to:

Docker Enterprise Edition
Docker Community Edition on the desktop with Docker for Mac and Windows
The Moby Project

Docker is a platform that sits between apps and infrastructure. By building apps on Docker, developers and IT operations get freedom and flexibility. That’s because Docker runs everywhere that enterprises deploy apps: on-prem (including on IBM mainframes, enterprise Linux and Windows) and in the cloud. Once an application is containerized, it’s easy to re-build, re-deploy and move around, or even run in hybrid setups that straddle on-prem and cloud infrastructure.
The Docker platform is composed of many components, assembled in four layers:

containerd is an industry-standard container runtime implementing the OCI standards
Swarm orchestration that transforms a group of nodes into a distributed system
Docker Community Edition providing developers a simple workflow to build and ship container applications, with features like application composition, image build and management
Docker Enterprise Edition, to manage an end to end secure software supply chain and run containers in production

These four layers are assembled from upstream components that are part of the open source Moby Project.
Docker’s design philosophy has always been about providing choice and flexibility. This is important for customers that are integrating Docker with existing IT systems, and that’s why Docker is built to work well with already-deployed networking, logging, storage, load balancers and CI/CD systems. For all of these (and more), Docker relies on industry-standard protocols or published and documented interfaces. And for all of these, Docker Enterprise Edition ships with sensible defaults, but those defaults can be swapped for certified third party options for customers that have existing systems or prefer an alternative solution.
In 2016, Docker added orchestration to the platform, powered by the SwarmKit project. In the past year, we’ve received lots of positive feedback on Swarm: it’s easy to set up, is scalable and is secure out-of-the-box.
We’ve also gotten feedback that some users really like the integrated Docker platform with end-to-end container management, but that they want to use other orchestrators, like Kubernetes, for container scheduling. Either because they’ve already designed services to work on Kubernetes or because Kubernetes has particular features they’re looking for. This is why we are adding Kubernetes support as an orchestration option (alongside Swarm) in both Docker Enterprise Edition, and in Docker for Mac and Windows.

We’re also working on innovative components that make it easier for Docker users to deploy Docker apps natively with Kubernetes orchestration. For example, by using Kubernetes extension mechanisms like Custom Resources and the API server aggregation layer, the coming version of Docker with Kubernetes support will allow users to deploy their Docker Compose apps as Kubernetes-native Pods and Services.
With the next version of the Docker platform, developers can build and test apps destined for production directly on Kubernetes, on their workstation. And ops can get all the benefits of Docker Enterprise Edition – secure multi-tenancy, image scanning and role-based access control – while running apps in production orchestrated with either Kubernetes or Swarm.
The Kubernetes version that we’re incorporating into Docker will be the vanilla Kubernetes that everyone is familiar with, direct from the CNCF.  It won’t be a fork, nor an outdated version, nor wrapped or limited in any way.
Through the Moby Project, Docker has been working to adopt and contribute to Kubernetes over the last year. We’ve been working on containerd (now 1.0)  and cri-containerd for the container runtime, on InfraKit for creating and managing Kubernetes installs, and on libnetwork for overlay networking. See the Moby Project blog post for more examples and details.
Docker and Kubernetes share much lineage, are written using the same programming language and have overlapping components, contributors and ideals. We at Docker are excited to have Kubernetes support in our products and into the open source projects we work on. And we can’t wait to work with the Kubernetes community to make containers and container-orchestration ever more powerful and easier to use.
While we’re adding Kubernetes as an orchestration option in Docker, we remain committed to Swarm and our customers and users that rely on Swarm and Docker for running critical apps at scale in production. To learn more about how Docker is integrating Kubernetes, check out the sessions “What’s New in Docker” and “Gordon’s Secret Session” at DockerCon EU.
Where to go from here?

Sign up for the Kubernetes for Docker beta
Docker Enterprise Edition with Kubernetes
Community Edition for Mac and Windows with Kubernetes
Moby and Kubernetes

#Docker Platform and @Moby Project add @KubernetesioClick To Tweet

The post Top 5 Blogs of 2017: Docker Platform and Moby Project add Kubernetes appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Using Docker to Scale Operational Intelligence at Splunk

Splunk wants to make machine data accessible, usable and valuable to everyone. With over 14,000 customers in 110 countries, providing the best software for visualizing machine data involves hours and hours of testing against multiple supported platforms and various configurations. For Mike Dickey, Sr. Director in charge of engineering infrastructure at Splunk, the challenge was that 13 different engineering teams in California and Shanghai had contributed to test infrastructure sprawl, with hundreds of different projects and plans that were all being managed manually.
At DockerCon Europe, Mike and Harish Jayakumar, Docker Solutions Engineer, shared how Splunk leveraged Docker Enterprise Edition (Docker EE) to dramatically improve build and deployment times on their test infrastructure, converge on a unified Continuous Integration (CI) workflow, and how they’ve now grown to 600 bare-metal servers deploying tens of thousands of Docker containers per day.
You can watch the entire session here:

Hitting the Limits of Manual Test Configurations
As Splunk has grown, so has their customers’ use of their software. Many Splunk customers now process petabytes of data, and that has forced Splunk to scale their testing to match. That means more infrastructure needs to be reserved in the shared test environment for these large-scale tests. Besides running out of data center capacity, reserving test infrastructure was being managed manually through a Wiki page – a process with obvious limitations.

At the time Mike was leading the Performance Engineering team, and they had started working with Docker containers. Seeing near-bare metal performance for containerized applications, Splunk began to test Docker in smaller proof-of-concept projects and saw that it could be effective for performance testing. They saw the ability to leverage Docker as the foundation for a unified test and CI platform.
Building a App Development Platform with Docker EE

Splunk chose Docker EE to power their test and CI platform for a few key reasons:

Windows and Linux support: Splunk software runs on both Linux and Windows and so they wanted a single solution that could support both Linux and Windows
Role-Based Access Control: As the environment is a shared resource between multiple teams, Splunk needed a way to integrate with Active Directory and assign resources by roles.
Consistent Dev Experience: With most developers already using Docker on their desktops, Splunk wanted to maintain a consistent experience with support for Docker APIs and the use of Compose files.
Vendor to Partner With: Given the scale of this project, Splunk wanted to work with a vendor who would be their partner. A bonus was that our offices were only a few blocks apart.

Results and What’s Next
Today, Docker EE powers Splunk’s CI and test platforms. As part of the CI solution, Splunk is leveraging Docker to create an agentless Jenkins workflow where each build stage is replaced by a container. This delivers a more consistent and scalable experience (2000 concurrent jobs today vs. 200 per master with standard agents) that is much more efficient as well. For performance testing, teams can reserve an entire host to get accurate performance results. These can be dynamically provisioned for different configurations in minutes instead of days.

At Splunk, the Docker EE environment has grown from 150 servers to now 600 servers, starting with one team of developers to now 385 unique developers who deploy between 10,000 and 20,000 containers a day. In addition to the fast deployment times, Splunk is seeing more efficient use of the hardware than before, averaging 75% utilization of the available capacity. With the platform in place, the developers at Splunk have a simple and fast way to provision and execute tests. As a result, Splunk has seen an increase in testing frequency, which is helping to improve product quality.

Check out how @Splunk used #Docker EE to scale and deploy 10,000+ containers per dayClick To Tweet

To learn more about Docker EE, check out the following resources:

Learn more about Docker EE
Try Docker EE for yourself
Contact Sales for more information

The post Using Docker to Scale Operational Intelligence at Splunk appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/