Kategorie: 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/

5 tips to learn Docker in 2018

As the holiday season ends, many of us are making New Year’s resolutions for 2018. Now is a great time to think about the new skills or technologies you’d like to learn. So much can change each year as technology progresses and companies are looking to innovate or modernize their legacy applications or infrastructure. At the same time the market for Docker jobs continues to grow as companies such as Visa, MetLife and Splunk adopt Docker Enterprise Edition ( EE) in production. So how about learning Docker in 2018 ? Here are a few tips to help you along the way.
 

1. Play With Docker: the Docker Playground and Training site
 
Play with Docker (PWD) is a Docker playground and training site which allows users to run Docker commands in a matter of seconds. It gives the experience of having a free Linux Virtual Machine in browser, where you can build and run Docker containers and even create clusters. Check out this video from DockerCon 2017 to learn more about this project. The training site is composed of a large set of Docker labs and quizzes from beginner to advanced level available for both Developers and IT pros at  training.play-with-docker.com.

 
2. DockerCon 2018
 
In case you missed it, DockerCon 2018 will take place at Moscone Center, San Francisco, CA on June 13-15, 2018. DockerCon is where the container community comes to learn, belong, and collaborate. Attendees are a mix of beginner, intermediate, and advanced users who are all looking to level up their skills and go home inspired. With a 2 full days of training, more than 100 sessions, free workshops and hands-on labs and the wealth of experience brought by each attendee, DockerCon is the place to be if you’re looking to learn Docker in 2018.

 
3. Docker Meetups
 
Look at our Docker Meetup Chapters page to see if there is a Docker user group in your city. With more than 200 local chapters in 81 countries, you should be able to find one near you! Attending local Docker meetups are an excellent way to learn Docker. The community leaders who run the user group often schedule Docker 101 talks and hands-on training for newcomers!
Can’t find a chapter near you? Join the Docker Online meetup group to attend meetups remotely!

 
4. Docker Captains
 
Captains are Docker experts that are leaders in their communities, organizations or ecosystems. As Docker advocates, they are committed to sharing their knowledge and do so every chance they get! Captains are advisors, ambassadors, coders, contributors, creators, tool buil
ders, speakers, mentors, maintainers and super users and are required to be active stewards of Docker in order to remain in the program.
Follow all of the Captains on twitter. Also check out the Captains GitHub repo to see what projects they have been working on. Docker Captains are eager to bring their technical expertise to new audiences both offline and online around the world – don’t hesitate to reach out to them via the social links on their Captain profile pages. You can filter the captains by location, expertise, and more.

5. Training and Certification
 
The new Docker Certified Associate (DCA) certification, launching at DockerCon Europe on October 16, 2017, serves as a foundational benchmark for real-world container technology expertise with Docker Enterprise Edition. In today’s job market, container technology skills are highly sought after and this certification sets the bar for well-qualified professionals. The professionals that earn the certification will set themselves apart as uniquely qualified to run enterprise workloads at scale with Docker Enterprise Edition and be able to display the certification logo on r
esumes and social media profiles. Want to be as prepared as you can be? Check out our study guide with sample questions and exam preparation tips before you schedule your exam.
 

 

5 tips to learn #docker in 2018: @playwithdocker @dockercon #dockercaptain #dockermeetupClick To Tweet

The post 5 tips to learn Docker in 2018 appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

MetLife Uses Docker Enterprise Edition to Self Fund Containerization

MetLife is a 150 year old company in the business of securing promises and the information management of over 100M customers and their insurance policies. As a global company, MetLife delivers promises into every corner of the world – some of them built to last a lifetime. With this rich legacy comes a diverse portfolio of IT infrastructure to maintain those promises.
In April, Aaron Aedes from MetLife spoke about their first foray into Docker containerization with a new application, GSSP, delivered through Azure. Six months later, MetLife returns to the DockerCon stage to share their journey since this initial deployment motivated them to find other ways to leverage Docker Enterprise Edition [EE] within MetLife.
Jeff Murr, Director of Engineering for Containers and Open Source at MetLife spoke in the Day 1 DockerCon keynote session about how they are looking to scale containerization with Docker as they scale . He states that new technology typically adds more cost and overhead to an already taxed IT budget. But the Docker Modernize Traditional Apps [MTA] Program presented an opportunity to reduce the costs of their existing applications.
The MTA project at MetLife started with a single Linux Java-based application that handled the “Do Not Call / Opt out” process, a simple but important application in handling the customer experience. The app was containerized with Docker EE in a single day and they immediately saw improvements in the time to deploy and scale the application in addition to the amount of resources the app now required as a Docker EE container.

The Business Case for Traditional Apps in Docker EE
After a successful MTA POC, Jeff’s team looked at the rest of their application landscape to find other applications that were candidates for modernization.. Of the almost 6,000 applications at MetLife, 593 of them (roughly 10%) used the same technology stack as the application from the MTA POC. The resulting analysis projected a 66% total cost savings for those 593 applications. This savings represents not only the infrastructure efficiency gains but also the time saved in maintaining and supporting the application — for their US operations only. This represents tens of millions of dollars in savings for MetLife – and it all started with a single application.

“The do-not-call app wasn’t an exciting app – it is pretty exciting now.” Jeff Murr, MetLife

For Jeff’s team, this project has created a repeatable model to offer to the various application teams within MetLife whether the applications are Windows or Linux. Docker EE created a unique opportunity where the disruption itself is self-funded while providing a platform to innovate at scale. With Docker and by migrating to the cloud,MetLife is able to   flip the 80/20 maintenance-to-innovation ratio on its head.
Begin Your Journey
Companies looking to get started with Docker Enterprise Edition can take some tips from the experience at MetLife with both containerizing an existing application as well as building and deploying new microservices. The key is to start small and incrementally innovate with one app, one technology stack at a time and ease the operational changes over time, establish a pattern, rinse and repeat.

To learn more about Docker Enterprise Edition:

Learn more about Docker EE
Try Docker EE for free and view subscription plans 
Register for the Modernize Traditional Apps Digital Kit
Sign up for upcoming webinars

Hear it from the customer! Learn how @MetLife used #Docker Enterprise Edition to reduce the costs…Click To Tweet

The post MetLife Uses Docker Enterprise Edition to Self Fund Containerization appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/