da Agency

Docker Online Meetup # 41: Docker Captains Share their Tips and Tricks for Built In Docker Orchestration

It’s been nearly two weeks since Docker released Docker 1.12 as generally available for production environments, introducing a number of new features and concepts to the Docker project. Our #DockerCaptain team has already started to dig in and share their learnings with the community via blog posts, talks and peer-to-peer help. Docker Captains are technology experts who have been awarded the distinction of being a Docker Captain in part because of their passion for sharing their Docker knowledge with others. So, we’ve invited three of our Docker Captains to speak at the next Docker Online Meetup on August 31st and share their tips and tricks for using Docker 1.12.

Ajeet Singh Raina is currently working as Technical Lead Engineer in the Enterprise Solution Group at Dell India R&D and has solid understanding of a diverse range of IT infrastructure, system management, system integration engineering and quality assurance. Ajeet has a great passion for upcoming trends and technologies. He loves contributing towards Open source space through writing and blogging @ http://www.collabnix.com.
Ajeet has shared a number of fantastic articles on Service Discovery, including Demonstrating Docker 1.12 Service Discovery with Docker Compose and How Service Discovery works under Docker Engine 1.12. In the meetup, Ajeet will quickly share his key takeaways and the best ways to use Docker 1.12 Service Discovery.

Viktor Farcic is a Senior Consultant at CloudBees. He coded using a plethora of languages starting and can often be found speaking about Docker around the world. His big passions are Microservices, Continuous Integration, Delivery and Deployment (CI/CD) and Test-Driven Development (TDD).  He wrote The DevOps 2.0 Toolkit: Automating the Continuous Deployment Pipeline with Containerized Microservices and the Test-Driven Java Development books. His random thoughts and tutorials can be found on his blog TechnologyConversations.com.
If you haven’t had the chance to check out Viktor’s Docker Swarm Introduction and Integrating Proxy With Docker Swarm (Tour Around Docker 1.12 Series), you are going to want to make some time to dive in. Viktor covers the basics of how Swarm in Docker v1.12 works and then deep-dives into some of the more complicated aspects. In the meetup, Viktor will share best practices for setting a Swarm cluster and integrating it with HAProxy.

For 20 years Bret Fisher has designed, built, and operated distributed systems from 4 to 4000. He currently focuses on DevOps style activities in the public cloud and enterprise. Bret works on creating immutable infrastructures, automation, containers, CI/CD, cloud monitoring, and an occasional JavaScript developer. He spends his free time in Virginia’s local, thriving tech scene helping lead local Code for America and Docker Meetup groups. He basically spend his days helping people. Bret lives at the beach. Dogs over Cats.
Bret frequents Docker forums to lend a helping hand when others get stuck, so he knows a thing or two about how to optimize getting started with 1.12. Bret will share his favorite Docker 1.12 command options and aliases that will make your life easier including cli aliases for quick container management; the shortest path to secure production-ready swarm; how to use cli filters for easier management of larger swarms; and docker remote cli security setup.
Register now to attend the meetup and learn tips and tricks for using Docker 1.12!

Join @Docker Captains @ajeetsraina @BretFisher @vfarcic to learn about @docker 1.12 built in…Click To Tweet

Quelle: https://blog.docker.com/feed/

da Agency

Your Docker Agenda in August

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

North America | South America | Europe | Oceania | Asia | Africa | Official Docker Training Courses
 

Check out the @Docker agenda for August! Tons of awesome meetups, webinars & conferences!Click To Tweet

Official Docker Training Courses
View the full schedule of instructor led training courses here! Description of courses are below.

Docker Datacenter Training Series
Introduction to Docker
Docker Administration and Operations
Advanced Docker Operations
Managing Container Services with Universal Control Plane
Deploying Docker Datacenter
User Management and Troubleshooting UCP

North America
 
Aug 3rd: Docker Meetup at Docker HQ – San Francisco, CA
Come and join us at Docker HQ on Wednesday for our 47th meetup! Ben Bonnefoy , a member of the Docker technical staff, will give an insight into Docker for Mac and Docker for Windows and then Nishant Totla , a software engineer in the core open source team, will give some updates on Docker #1.12. This will be followed by a talk by Neil Gehani , a Sr. Product Manager at HPE, on in-cluster testing. It will be a fun evening of learning, exchanging ideas and networking with pizza, beer and plenty of Docker stickers for everyone.
RSVP
Aug 3rd: Docker Meetup at Meltmedia &8211; Tempe, AZ
This meetup will focus on Docker for AWS, specifically running distributed apps from localhost to AWS.
RSVP
Aug 4th: Docker Meetup at Rackspace &8211; Austin, TX
A discussion about Docker Tips and Tricks.
RSVP
Aug 9th: Docker Meetup at CA Technologies &8211; Denver, CO
A talk about moving from SaaS to On-Premise with Docker, in particular how Docker made it possible to deploy a SaaS web application into firewalled networks and a journey of orchestrating together micro-service architecture from raw bash script to Replicated.
RSVP
Aug 11th: Docker Meetup at Full Sail Campus &8211; Orlando, FL
Docker Ecosystem and Use Case talks, followed by networking.
RSVP
Aug 11th: Docker Meetup at Braintree &8211; Chicago, IL
Ken Sipe will take the group through a look at the anatomy of a container including control groups (cgroups) and namespaces. Then there will be a discussion about Java’s memory management and GC characteristics and how JRE characteristics change based on core count.
RSVP
Aug 16th: Docker Meetup at AEEC Innovation Lab &8211; Alexandria, VA
Docker Captain, Phil Estes, will present.
RSVP
Aug 16th: Docker Meetup at Datastax &8211; Santa Clara, CA
Databases, Image Management, In-cluster and Chaos Testing talks by Baruch Sadogursky, Ben Bromhead and Neil Gehani.
RSVP
Aug 16th: Docker Meetup at Impact Hub &8211; Santa Barbara, CA
This meetup will be about leveraging Docker + Compose for a real world dev environment. James Brown from Invoca will discuss how the move to Docker has benefited their development process.
RSVP
Aug 18th: Docker Meetup at CirrusMio &8211; Lexington, KY
Come and learn how others are using Docker! There will be two demos/talks scheduled for this meetup. The first will be about using Jenkins to build containers and the second will be about Docker in production.
RSVP
Aug 18th: Docker Meetup in Minneapolis &8211; Minneapolis, MN
The Container Summit City Series comes to Minneapolis on August 18th to continue the conversation surrounding containers in production! Bryan Cantrell, CTO of Joyent, will be joined in speaking by other expert users from companies that have been running containers in production for years and have experience with what solution stacks work best and what pitfalls to avoid.
RSVP
Aug 22nd: Docker Meetup at Issuetrak &8211; Virginia Beach , VA
Bret Fisher will tell all about DockerCon 2016 and what&8217;s in store for Docker in 1.12.
Aug 22nd &8211; 24th: LinuxCon/ ContainerCon &8211; Toronto, CA
There’s plenty of us at LinuxCon/ ContainerCon this year! Come see us at Booth #41 to meet the Docker speakers and pick up your swag.
Aug 23rd: Docker and NATS Cloud Native Meetup During LinuxCon &8211; Toronto, Canada
The Docker Toronto meetup group and the Toronto NATS Cloud Native and IoT meetup group are joining forces to bring you a mega-meetup during LinuxCon! Riyaz Faizullabhoy from Docker will present on ‘The Update Framework&8217; and , Diogo Monteiro will discuss implementing microservices with NATS. Raffi Der Haroutiounian will give an overview of NATS, Docker and Microservices.
Aug 23rd: Docker Meetup at the Iron Yard &8211; Houston, TX
Join us for our next meetup event!
RSVP
Aug 24th: Docker Meetup at CodeGuard &8211; Atlanta, GA
Talk by Eldon Stegall entitled, &8216;Abusing The Bridge: Booting a baremetal cluster from a docker container.&8217;
RSVP
Aug 28th &8211; 31h: VMworld 16 US &8211; Las Vegas, CA
Docker returns to VMworld this year and in Las Vegas! We’re launching our newest and biggest booth yet, so be sure to catch us at Booth #2362. Yes, there will be swag given away.
Aug 31st: Docker Meetup in Salt Lake City &8211; Salt Lake City , UT
Come for a tutorial on new Docker 1.12 features and a review of DockerCon 2016 by Ryan Walls.
RSVP

South America
 
Aug 4th: Docker Meetup at Globant &8211; Córdoba, Argentina
Come for a talk on Docker for AWS. Talks by Florencia Caro, Ruben Dopazo, Carlos Santiago Moreno y Luis Barrueco.
RSVP
Aug 6th: Docker Meetup at Universidad Interamericana de Panamá &8211; Panamá, Panama
An introduction to Docker and Docker Cluster.
RSVP
Aug 9th: Docker Meetup at VivaReal&8211; Sao Paulo, Brazil
RSVP
Aug 13th: Docker Meetup at Microsoft Peru &8211; Lima, Peru
Join for a DockerCon recap.
RSVP
Aug 20th: Docker Meetup at Auditório-Unijorge Campus Comércio &8211; Salvador, Brazil
This is the beginning of the Docker Tour: the Docker Salvador meetup group&8217;s initiate to spread Docker technology among IT students in Salvador. This event will have two lectures for beginners where they can install the tool and learn Docker at ease in a friendly environment.
RSVP
Aug 23rd: Docker Meetup at Auditório Tecnopuc &8211; Porto Alegre, Brazil
A meetup to discuss PHP and Docker.
RSVP

Europe
 
Aug 3rd: Docker HandsOn &8211; Meet-Repeat C##n+1 &8211; Hamburg, Germany
Aug 4th: Docker Meetup at SkyScanner Glasgow &8211; Glasgow, United Kingdom
What&8217;s new in Docker Land (@rawkode and @GJTempleton). Guy & I will be walking you through all the latest developments in Docker Land, including Docker Engine 1.12, Docker Compose 1.8, and Docker for Mac and Windows. Also well as these Docker updates, we&8217;ll be providing a quick review of DockerCon 2016 and highlighting some of the best talks for you to watch in your own time.
RSVP
Aug 8th: Docker Talk at Golang Conference &8211; Golang, UK
Speaking Docker Captain Tiffany Jernigan
Aug 9th: IOT RpiCar si ASP.NET Core + Docker &8211; Bucharest, Romania
Aug 10th:  Docker Meetup at KWORKS &8211; Istanbul, Turkey
Dockerizing a Complex Application Stack [w/Istanbul DevOps]
Aug 24th: Docker Meetup at Pipedrive &8211; Tallinn, Estonia
Let&8217;s share and discuss our experience with Docker ecosystem. More details of the content coming up!
RSVP
Aug 24th: Docker Meetup at Elastx &8211; Stockholm, Sweden
Continuously Deploying Containers To Docker Swarm Cluster. Speaker: Viktor Farcic (Docker Captain), & Senior Consultant, CloudBees. Abstract: Many of us have already experimented with Docker &8211; for example, running one of the pre-built images from Docker Hub. It is possible that your team might have recognized the benefits that Docker, in conjunction with experimentation, provides in building microservices and the advantages the technology could bring to development, testing, integration, and, ultimately, production.
RSVP
Aug 25th: Day of Containers &8211; Stockholm &8211; Stockholm, Sweden
Andrey Devyatkin & Viktor Farcic (Docker Captain) will give a talk “Docker 101.” If you are new to docker, this session is for you! In this sessions you will learn all the basics of docker and its main components. We will go through the the concept of containers, writing your own docker files, connecting data volumes, and basic orchestration with compose and swarm. Bring your laptops!
Aug 28th: Docker Meetup at Praqma &8211; Copenhagen, Denmark
Continuously Deploying Containers To Docker Swarm Cluster. Speaker: Viktor Farcic, Docker Captain & Senior Consultant, CloudBees. Abstract: Many of us have already experimented with Docker &8211; for example, running one of the pre-built images from Docker Hub. It is possible that your team might have recognized the benefits that Docker, in conjunction with experimentation, provides in building microservices and the advantages the technology could bring to development, testing, integration, and, ultimately, production.
RSVP
Aug 28th: Docker Talk at Agile Peterborough &8211; Peterborough, UK
Speaker Docker Captain Alex Ellis
Aug 28th: Docker Pre- Conference Meetup &8211; Praqma, Copenhagen
Speaker Docker Captain Viktor Farcic
Aug 29th: Docker Meetup at Praqma &8211; Copenhagen, Denmark
Laura Frank (Docker Captain) &8211; &8220;Stop being lazy and test your software.&8221; Testing software is necessary, no matter the size or status of your company. Introducing Docker to your development workflow can help you write and run your testing frameworks more efficiently, so that you can always deliver your best product to your customers and there are no excuses for not writing tests anymore. Jan Krag &8211; &8220;Docker 101.&8221; If you are new to docker, this session is for you! In this sessions you will learn all the basics of docker and its main components.
Viktor Farcic (Docker Captain)

Aug 31st: Docker Meetup at INCUBA &8211; Aarhus, Denmark
Rohde & Schwarz will give a talk about how they use Docker for development and test. HLTV.org will give a talk about how they use Docker to easily deploy microservices as part of their web platform.
RSVP
Aug 31st &8211; Sep 2: Software Circus &8211; Amsterdam, Netherlands
In Amsterdam for Software Circus? So is Docker! Speaking from Docker Ben Firshman

Asia
 
Aug 20th: Docker Meetup at Red Hat India Pvt. Ltd &8211; Bangalore, India
Docker for AWS and Azure &8211; Neependra Khare (Docker Captain), CloudYuga. Service Discovery and Load Balancing with Docker Swarm &8211; Ajeeth S. Raina (Docker Captain), Dell. Docker Application Bundle Overview &8211; Thomas Chacko. Logging as a service using Docker &8211; Manoj Goyal, Cisco. SDN-Like App Delivery Controller using Docker Swarm &8211; Prasad Rao, Avi Networks.
RSVP

Oceania 
Aug 1st: Docker Meetup in Auckland &8211; Auckland, New Zealand
Learn about all the new Docker features and offerings announced at DockerCon16 in Seattle!
RSVP
Aug 8th: Docker Meetup at Commbank &8211; Sydney, Australia
The Big Debate: AWS v Azure vs Google Cloud vs EMC Hybrid Cloud. One of the questions will help bring to light each platform&8217;s integration with the Docker ecosystem.
RSVP

Africa
Aug 6th: Docker Meetup at LakeHub &8211; Kisumu, Kenya
Please join us to learn about all the exciting announcements from DockerCon! Talk 1: What&8217;s New in Docker 1.12, by William Ondenge. In this presentation, William will describe Docker 1.12 new features and help you get your hands on the latest builds of Docker to try them on your own.
RSVP
// <![CDATA[
!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s); js.id=id;js.async=true;js.src="https://a248.e.akamai.net/secure.meetupstatic.com/s/script/2012676015776998360572/api/mu.btns.js?id=65gk05ie6n07ijoq3eq5vchs6f";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","mu-bootjs");
// ]]>
Quelle: https://blog.docker.com/feed/

da Agency

Continuous Integration Testing on Docker Cloud. It’s Dead Simple

This is a guest post by Stephen Pope & Kevin Kaland from Project Ricochet
Docker Cloud is a SaaS solution hosted by Docker that gives teams the ability to easily manage, deploy, and scale their Dockerized applications.

The Docker Cloud service features some awesome continuous integration capabilities, especially its testing features. Once you understand the basics, I’ve found they are remarkably easy to use. The fact is, continuous integration covers a wide range of items — like automated builds, build testing, and automated deployment. The Docker Cloud service makes features like automated builds and deployment quite obvious, but the testing features can be a little harder to find, even though they are in plain sight!
In this piece, my aim is to walk you through the Docker Cloud service’s testing capabilities in a straightforward manner. By the end, I hope you’ll agree that it’s really dead simple!
So, let’s begin with the first task. Before we can test our builds, we need to automate them. We’ll use GitHub to set this up here, but note that it works the same way in Bitbucket.
Setup an Automated Build

1. Log into Docker Cloud using your Docker ID.
2. On the landing page (or in the left-hand menu), click on Repositories.
3. If you don’t already have a repository, you’ll need to click the Create button on the Repository page.
4. Click the Builds tab on the Repository page. If this is your first autobuild, you should see this screen:

To connect your GitHub account, click the Learn more link.
5. Once on the Cloud Settings page, look for the Source Providers section. Click on the plug  icon to connect your GitHub account. Authorize the connection on the screen that follows.

6. When your GitHub account is connected, go back to the Repository page and click Configure Automated Builds. Now we are in business!
7. Select the GitHub source repository you want to build from.

8. In the Build Location section, choose the option to Build on Docker Cloud’s infrastructure and select a builder size to run the build process on. Accept the default Autotest option for now (we’ll describe the Autotest options in detail in a moment).

Make sure you are satisfied with the Tag Mappings; these map your Docker image build tags (e.g. latest, test, production, etc.) to your GitHub branches. Ensure that Autobuild is enabled. If your Dockerfile needs any Environment Variables at build time, you can add them here. (Ours doesn’t.) Once you&8217;ve set everything up, click Save.
The specified tag will now be built when you push to the associated branch:

Setup Automated Deployment
After the build images are created, you can enable automated deployment.
If you are inclined to build images automatically, you may also want to automate the deployment of updated images once they are built. Docker Cloud makes this easy:
1. To get started, you will need a service to deploy (a service is a collection of running containers of a particular Docker image). A good example of a service might be our production node app, running 7 containers with a set of environment variables setup for that specific instance of the app. You might also have an equivalent service for development and testing (where you can test code before production). Here is a good read on starting your first service
2. Edit the service that is using the Docker image.
3. In the General Settings section, ensure that Autoredeploy is enabled:

4. Save changes and you should be set.
Autotest Builds before Deployment
Remember when I said testing your builds was dead simple? Well, check this out. All you need to do is enable Autotests.
On the Repository page, navigate to the Builds tab and then click Configure Automated Builds. Within the Autotest section, three options are available:

Off will test commits only to branches that are using Autobuild to build and push images.
Source repository will test commits to all branches of the source code repository, regardless of their Autobuild setting.
Source repository and external pull requests will test commits to all branches of the source code repository, including any pull requests opened against it.

Before you turn that on, you’ll need to set up a few assets in your repository to define the tests and how they should be run. You can find examples of this in our Production Meteor using Docker Git repo.
This boils down to a single basic file — plus some optional ones in case you need them.
Our docker-compose.test.yml will serve as the main entry point for testing. It lets you define a “sut” service. This enables you to run the main tests and various other services that may be needed to test your build. In our example, you may notice that it simply outputs “test passed” — but that line is where the magic happens. If your test returns 0, your test has passed. If it returns a 1, it hasn’t. Essentially, you are performing a simple call from the YAML file, or if more complex tests are done, in a more robust bash script.
Let’s review a YAML compose file example from a blog on automated testing that uses a bash script and some additional features:
sut:
 build: .
 dockerfile: Dockerfile.test
 links:
   &8211; web
web:
 build: .
 dockerfile: Dockerfile
 links:
   &8211; redis
redis:
 image: redis
Here, we define a sut service, along with some build instructions and an additional dockerfile for the tests. With this, you should be able to build a separate image for testing, instead of using the image for your build. That enables you to have different packages and files for testing that won’t be included in your application build.
Docker.test
FROM ubuntu:trusty
RUN apt-get update && apt-get install -yq curl && apt-get clean
WORKDIR /app
ADD test.sh /app/test.sh
CMD [&8220;bash&8221;, &8220;test.sh&8221;]
Here you’ll notice the final CMD is a test.sh bash script. This script will execute and return a 0 or 1 based on the test results.
Let’s take a quick look at the test.sh script:
Test.sh
sleep 5
if curl web | grep -q &8216;<b>Visits:</b> &8216;; then
 echo &8220;Tests passed!&8221;
 exit 0
else
 echo &8220;Tests failed!&8221;
 exit 1
fi
You’ll see the script is doing a simple curl call against the test application to see if some text appears on the page. If it does, the test passed. If not, the test will fail.
Remember how easy I said this was to implement on Docker Cloud? That&8217;s all there is to it! Additionally once you’ve mastered the basics, more advanced integrations can be done with builds hooks.
Of course, building the tests for a complete application will be a much larger task than described here, but the point is you’ll be able to focus on the tests, not how to squeeze them into your CI workflow. Docker Cloud makes the setup and implementation super easy. Once you understand these basic components, you should be able to set up our test Meteor service up in a matter of minutes.
Alright, that’s it for now. I hope this piece helped guide you through the process fairly easily, and more importantly showcases the cool testing CI workflow Docker Cloud has to offer. If you have additional questions or comments, make sure to head over to the Docker Cloud Forum, Docker technical staff will be glad to help. Here are some related posts that should prove helpful on your journey. Enjoy!
Get Docker Cloud for Free &8211; https://cloud.docker.com/

Docker Cloud Automated Repository Testing
Basic Voting Webapp (used at DockerCon for various examples)
An in depth post on automated test on Digital Ocean
Meteor Docker Example with Test (used in this Blog)

@Docker Cloud Service features continuous integration capabilities #learndocker!Click To Tweet

Quelle: https://blog.docker.com/feed/

da Agency

The Bet on Kubernetes, a Red Hat Perspective

Editor’s note: Today’s guest post is from a Kubernetes contributor Clayton Coleman, Architect on OpenShift at Red Hat, sharing their adoption of the project from its beginnings.Two years ago, Red Hat made a big bet on Kubernetes. We bet on a simple idea: that an open source community is the best place to build the future of application orchestration, and that only an open source community could successfully integrate the diverse range of capabilities necessary to succeed. As a Red Hatter, that idea is not far-fetched – we’ve seen it successfully applied in many communities, but we’ve also seen it fail, especially when a broad reach is not supported by solid foundations. On the one year anniversary of Kubernetes 1.0, two years after the first open-source commit to the Kubernetes project, it’s worth asking the question:Was Kubernetes the right bet?The success of software is measured by the successes of its users – whether that software enables for them new opportunities or efficiencies. In that regard, Kubernetes has succeeded beyond our wildest dreams. We know of hundreds of real production deployments of Kubernetes, in the enterprise through Red Hat’s multi-tenant enabled OpenShift distribution, on Google Container Engine (GKE), in heavily customized versions run by some of the world’s largest software companies, and through the education, entertainment, startup, and do-it-yourself communities. Those deployers report improved time to delivery, standardized application lifecycles, improved resource utilization, and more resilient and robust applications. And that’s just from customers or contributors to the community – I would not be surprised if there were now thousands of installations of Kubernetes managing tens of thousands of real applications out in the wild.I believe that reach to be a validation of the vision underlying Kubernetes: to build a platform for all applications by providing tools for each of the core patterns in distributed computing. Those patterns:simple replicated web softwaredistributed load balancing and service discoveryimmutable images run in containersco-location of related software into podssimplified consumption of network attached storageflexible and powerful resource schedulingrunning batch and scheduled jobs alongside service workloadsmanaging and maintaining clustered software like databases and message queuesAllow developers and operators to move to the next scale of abstraction, just like they have enabled Google and others in the tech ecosystem to scale to datacenter computers and beyond. From Kubernetes 1.0 to 1.3 we have continually improved the power and flexibility of the platform while ALSO improving performance, scalability, reliability, and usability. The explosion of integrations and tools that run on top of Kubernetes further validates core architectural decisions to be composable, to expose open and flexible APIs, and to deliberately limit the core platform and encourage extension.Today Kubernetes has one of the largest and most vibrant communities in the open source ecosystem, with almost a thousand contributors, one of the highest human-generated commit rates of any single-repository project on GitHub, over a thousand projects based around Kubernetes, and correspondingly active Stack Overflow and Slack channels. Red Hat is proud to be part of this ecosystem as the largest contributor to Kubernetes after Google, and every day more companies and individuals join us. The idea of Kubernetes found fertile ground, and you, the community, provided the excitement and commitment that made it grow.So, did we bet correctly? For all the reasons above, and hundreds more: Yes.What’s next?Happy as we are with the success of Kubernetes, this is no time to rest! While there are many more features and improvements we want to build into Kubernetes, I think there is a general consensus that we want to focus on the only long term goal that matters – a healthy, successful, and thriving technical community around Kubernetes. As John F. Kennedy probably said: > Ask not what your community can do for you, but what you can do for your communityIn a recent post to the kubernetes-dev list, Brian Grant laid out a great set of near term goals – goals that help grow the community, refine how we execute, and enable future expansion. In each of the Kubernetes Special Interest Groups we are trying to build sustainable teams that can execute across companies and communities, and we are actively working to ensure each of these SIGs is able to contribute, coordinate, and deliver across a diverse range of interests under one vision for the project.Of special interest to us is the story of extension – how the core of Kubernetes can become the beating heart of the datacenter operating system, and enable even more patterns for application management to build on top of Kubernetes, not just into it. Work done in the 1.2 and 1.3 releases around third party APIs, API discovery, flexible scheduler policy, external authorization and authentication (beyond those built into Kubernetes) is just the start. When someone has a need, we want them to easily find a solution, and we also want it to be easy for others to consume and contribute to that solution. Likewise, the best way to prove ideas is to prototype them against real needs and to iterate against real problems, which should be easy and natural.By Kubernetes’ second birthday, I hope to reflect back on a long year of refinement, user success, and community participation. It has been a privilege and an honor to contribute to Kubernetes, and it still feels like we are just getting started. Thank you, and I hope you come along for the ride!– Clayton Coleman, Contributor and Architect on Kubernetes and OpenShift at Red Hat. Follow him on Twitter and GitHub: @smarterclayton
Quelle: kubernetes

da Agency

A Very Happy Birthday Kubernetes

Last year at OSCON, I got to reconnect with a bunch of friends and see what they have been working on. That turned out to be the Kubernetes 1.0 launch event. Even that day, it was clear the project was supported by a broad community — a group that showed an ambitious vision for distributed computing. Today, on the first anniversary of the Kubernetes 1.0 launch, it’s amazing to see what a community of dedicated individuals can do. Kubernauts have collectively put in 237 person years of coding effort since launch to bring forward our most recent release 1.3. However the community is much more than simply coding effort. It is made up of people — individuals that have given their expertise and energy to make this project flourish. With more than 830 diverse contributors, from independents to the largest companies in the world, it’s their work that makes Kubernetes stand out. Here are stories from a couple early contributors reflecting back on the project:Sam Ghods, services architect and co-founder at BoxJustin Santa Barbara, independent Kubernetes contributorClayton Coleman, contributor and architect on Kubernetes on OpenShift at Red HatThe community is also more than online GitHub and Slack conversation; year one saw the launch of KubeCon, the Kubernetes user conference, which started as a grassroot effort that brought together 1,000 individuals between two events in San Francisco and London. The advocacy continues with users globally. There are more than 130 Meetup groups that mention Kubernetes, many of which are helping celebrate Kubernetes’ birthday. To join the celebration, participate at one of the 20 #k8sbday parties worldwide: Austin, Bangalore, Beijing, Boston, Cape Town, Charlotte, Cologne, Geneva, Karlsruhe, Kisumu, Montreal, Portland, Raleigh, Research Triangle, San Francisco, Seattle, Singapore, SF Bay Area, or Washington DC.The Kubernetes community continues to work to make our project more welcoming and open to our kollaborators. This spring, Kubernetes and KubeCon moved to the Cloud Native Compute Foundation (CNCF), a Linux Foundation Project, to accelerate the collaborative vision outlined only a year ago at OSCON …. lifting a glass to another great year.– Sarah Novotny, Kubernetes Community Wonk
Quelle: kubernetes

da Agency

Happy Birthday Kubernetes. Oh, the places you’ll go!

Editor’s note, Today’s guest post is from an independent Kubernetes contributor, Justin Santa Barbara, sharing his reflection on growth of the project from inception to its future.Dear K8s,It’s hard to believe you’re only one – you’ve grown up so fast. On the occasion of your first birthday, I thought I would write a little note about why I was so excited when you were born, why I feel fortunate to be part of the group that is raising you, and why I’m eager to watch you continue to grow up!–JustinYou started with an excellent foundation – good declarative functionality, built around a solid API with a well defined schema and the machinery so that we could evolve going forwards. And sure enough, over your first year you grew so fast: autoscaling, HTTP load-balancing support (Ingress), support for persistent workloads including clustered databases (PetSets). You’ve made friends with more clouds (welcome Azure & OpenStack to the family), and even started to span zones and clusters (Federation). And these are just some of the most visible changes – there’s so much happening inside that brain of yours!I think it’s wonderful you’ve remained so open in all that you do – you seem to write down everything on Github – for better or worse. I think we’ve all learned a lot about that on the way, like the perils of having engineers make scaling statements that are then weighed against claims made without quite the same framework of precision and rigor. But I’m proud that you chose not to lower your standards, but rose to the challenge and just ran faster instead – it might not be the most realistic approach, but it is the only way to move mountains!And yet, somehow, you’ve managed to avoid a lot of the common dead-ends that other open source software has fallen into, particularly as those projects got bigger and the developers end up working on it more than they use it directly. How did you do that? There’s a probably-apocryphal story of an employee at IBM that makes a huge mistake, and is summoned to meet with the big boss, expecting to be fired, only to be told “We just spent several million dollars training you. Why would we want to fire you?”. Despite all the investment google is pouring into you (along with Redhat and others), I sometimes wonder if the mistakes we are avoiding could be worth even more. There is a very open development process, yet there’s also an “oracle” that will sometimes course-correct by telling us what happens two years down the road if we make a particular design decision. This is a parent you should probably listen to!And so although you’re only a year old, you really have an old soul. I’m just one of the many people raising you, but it’s a wonderful learning experience for me to be able to work with the people that have built these incredible systems and have all this domain knowledge. Yet because we started from scratch (rather than taking the existing Borg code) we’re at the same level and can still have genuine discussions about how to raise you. Well, at least as close to the same level as we could ever be, but it’s to their credit that they are all far too nice ever to mention it!If I would pick just two of the wise decisions those brilliant people made:Labels & selectors give us declarative “pointers”, so we can say “why” we want things, rather than listing the things directly. It’s the secret to how you can scale to great heights; not by naming each step, but saying “a thousand more steps just like that first one”.Controllers are state-synchronizers: we specify the goals, and your controllers will indefatigably work to bring the system to that state. They work through that strongly-typed API foundation, and are used throughout the code, so Kubernetes is more of a set of a hundred small programs than one big one. It’s not enough to scale to thousands of nodes technically; the project also has to scale to thousands of developers and features; and controllers help us get there.And so on we will go! We’ll be replacing those controllers and building on more, and the API-foundation lets us build anything we can express in that way – with most things just a label or annotation away! But your thoughts will not be defined by language: with third party resources you can express anything you choose. Now we can build Kubernetes without building in Kubernetes, creating things that feel as much a part of Kubernetes as anything else. Many of the recent additions, like ingress, DNS integration, autoscaling and network policies were done or could be done in this way. Eventually it will be hard to imagine you before these things, but tomorrow’s standard functionality can start today, with no obstacles or gatekeeper, maybe even for an audience of one.So I’m looking forward to seeing more and more growth happen further and further from the core of Kubernetes. We had to work our way through those phases; starting with things that needed to happen in the kernel of Kubernetes – like replacing replication controllers with deployments. Now we’re starting to build things that don’t require core changes. But we’re still still talking about infrastructure separately from applications. It’s what comes next that gets really interesting: when we start building applications that rely on the Kubernetes APIs. We’ve always had the Cassandra example that uses the Kubernetes API to self-assemble, but we haven’t really even started to explore this more widely yet. In the same way that the S3 APIs changed how we build things that remember, I think the k8s APIs are going to change how we build things that think.So I’m looking forward to your second birthday: I can try to predict what you’ll look like then, but I know you’ll surpass even the most audacious things I can imagine. Oh, the places you’ll go!– Justin Santa Barbara, Independent Kubernetes Contributor
Quelle: kubernetes

da Agency

Why OpenStack's embrace of Kubernetes is great for both communities

Today, Mirantis, the leading contributor to OpenStack, announced that it will re-write its private cloud platform to use Kubernetes as its underlying orchestration engine. We think this is a great step forward for both the OpenStack and Kubernetes communities. With Kubernetes under the hood, OpenStack users will benefit from the tremendous efficiency, manageability and resiliency that Kubernetes brings to the table, while positioning their applications to use more cloud-native patterns. The Kubernetes community, meanwhile, can feel confident in their choice of orchestration framework, while gaining the ability to manage both container- and VM-based applications from a single platform.The Path to Cloud NativeGoogle spent over ten years developing, applying and refining the principles of cloud native computing. A cloud-native application is:Container-packaged. Applications are composed of hermetically sealed, reusable units across diverse environments;Dynamically scheduled, for increased infrastructure efficiency and decreased operational overhead; and Microservices-based. Loosely coupled components significantly increase the overall agility, resilience and maintainability of applications.These principles have enabled us to build the largest, most efficient, most powerful cloud infrastructure in the world, which anyone can access via Google Cloud Platform. They are the same principles responsible for the recent surge in popularity of Linux containers. Two years ago, we open-sourced Kubernetes to spur adoption of containers and scalable, microservices-based applications, and the recently released Kubernetes version 1.3 introduces a number of features to bridge enterprise and cloud native workloads. We expect that adoption of cloud-native principles will drive the same benefits within the OpenStack community, as well as smoothing the path between OpenStack and the public cloud providers that embrace them.Making OpenStack betterWe hear from enterprise customers that they want to move towards cloud-native infrastructure and application patterns. Thus, it is hardly surprising that OpenStack would also move in this direction [1], with large OpenStack users such as eBay and GoDaddy adopting Kubernetes as key components of their stack. Kubernetes and cloud-native patterns will improve OpenStack lifecycle management by enabling rolling updates, versioning, and canary deployments of new components and features. In addition, OpenStack users will benefit from self-healing infrastructure, making OpenStack easier to manage and more resilient to the failure of core services and individual compute nodes. Finally, OpenStack users will realize the developer and resource efficiencies that come with a container-based infrastructure.OpenStack is a great tool for Kubernetes usersConversely, incorporating Kubernetes into OpenStack will give Kubernetes users access to a robust framework for deploying and managing applications built on virtual machines. As users move to the cloud-native model, they will be faced with the challenge of managing hybrid application architectures that contain some mix of virtual machines and Linux containers. The combination of Kubernetes and OpenStack means that they can do so on the same platform using a common set of tools.We are excited by the ever increasing momentum of the cloud-native movement as embodied by Kubernetes and related projects, and look forward to working with Mirantis, its partner Intel, and others within the OpenStack community to brings the benefits of cloud-native to their applications and infrastructure.–Martin Buhr, Product Manager, Strategic Initiatives, Google[1] Check out the announcement of Kubernetes-OpenStack Special Interest Group here, and a great talk about OpenStack on Kubernetes by CoreOS CEO Alex Polvi at the most recent OpenStack summit here.
Quelle: kubernetes

da Agency

Challenges of a Remotely Managed, On-Premises, Bare-Metal Kubernetes Cluster

Today’s post is written by Bich Le, chief architect at Platform9, describing how their engineering team overcame challenges in remotely managing bare-metal Kubernetes clusters. IntroductionThe recently announced Platform9 Managed Kubernetes (PMK) is an on-premises enterprise Kubernetes solution with an unusual twist: while clusters run on a user’s internal hardware, their provisioning, monitoring, troubleshooting and overall life cycle is managed remotely from the Platform9 SaaS application. While users love the intuitive experience and ease of use of this deployment model, this approach poses interesting technical challenges. In this article, we will first describe the motivation and deployment architecture of PMK, and then present an overview of the technical challenges we faced and how our engineering team addressed them.Multi-OS bootstrap modelLike its predecessor, Managed OpenStack, PMK aims to make it as easy as possible for an enterprise customer to deploy and operate a “private cloud”, which, in the current context, means one or more Kubernetes clusters. To accommodate customers who standardize on a specific Linux distro, our installation process uses a “bare OS” or “bring your own OS” model, which means that an administrator deploys PMK to existing Linux nodes by installing a simple RPM or Deb package on their favorite OS (Ubuntu-14, CentOS-7, or RHEL-7). The package, which the administrator downloads from their Platform9 SaaS portal, starts an agent which is preconfigured with all the information and credentials needed to securely connect to and register itself with the customer’s Platform9 SaaS controller running on the WAN.Node managementThe first challenge was configuring Kubernetes nodes in the absence of a bare-metal cloud API and SSH access into nodes. We solved it using the node pool concept and configuration management techniques. Every node running the agent automatically shows up in the SaaS portal, which allows the user to authorize the node for use with Kubernetes. A newly authorized node automatically enters a node pool, indicating that it is available but not used in any clusters. Independently, the administrator can create one or more Kubernetes clusters, which start out empty. At any later time, he or she can request one or more nodes to be attached to any cluster. PMK fulfills the request by transferring the specified number of nodes from the pool to the cluster. When a node is authorized, its agent becomes a configuration management agent, polling for instructions from a CM server running in the SaaS application and capable of downloading and configuring software.Cluster creation and node attach/detach operations are exposed to administrators via a REST API, a CLI utility named qb, and the SaaS-based Web UI. The following screenshot shows the Web UI displaying one 3-node cluster named clus100, one empty cluster clus101, and the three nodes.Cluster initializationThe first time one or more nodes are attached to a cluster, PMK configures the nodes to form a complete Kubernetes cluster. Currently, PMK automatically decides the number and placement of Master and Worker nodes. In the future, PMK will give administrators an “advanced mode” option allowing them to override and customize those decisions. Through the CM server, PMK then sends to each node a configuration and a set of scripts to initialize each node according to the configuration. This includes installing or upgrading Docker to the required version; starting 2 docker daemons (bootstrap and main), creating the etcd K/V store, establishing the flannel network layer, starting kubelet, and running the Kubernetes appropriate for the node’s role (master vs. worker). The following diagram shows the component layout of a fully formed cluster.Containerized kubelet?Another hurdle we encountered resulted from our original decision to run kubelet as recommended by the Multi-node Docker Deployment Guide. We discovered that this approach introduces complexities that led to many difficult-to-troubleshoot bugs that were sensitive to the combined versions of Kubernetes, Docker, and the node OS. Example: kubelet’s need to mount directories containing secrets into containers to support the Service Accounts mechanism. It turns out that doing this from inside of a container is tricky, and requires a complex sequence of steps that turned out to be fragile. After fixing a continuing stream of issues, we finally decided to run kubelet as a native program on the host OS, resulting in significantly better stability.Overcoming networking hurdlesThe Beta release of PMK currently uses flannel with UDP back-end for the network layer. In a Kubernetes cluster, many infrastructure services need to communicate across nodes using a variety of ports (443, 4001, etc..) and protocols (TCP and UDP). Often, customer nodes intentionally or unintentionally block some or all of the traffic, or run existing services that conflict with the required ports, resulting in non-obvious failures. To address this, we try to detect configuration problems early and inform the administrator immediately. PMK runs a “preflight” check on all nodes participating in a cluster before installing the Kubernetes software. This means running small test programs on each node to verify that (1) the required ports are available for binding and listening; and (2) nodes can connect to each other using all required ports and protocols. These checks run in parallel and take less than a couple of seconds before cluster initialization.MonitoringOne of the values of a SaaS-managed private cloud is constant monitoring and early detection of problems by the SaaS team. Issues that can be addressed without intervention by the customer are handled automatically, while others trigger proactive communication with the customer via UI alerts, email, or real-time channels. Kubernetes monitoring is a huge topic worthy of its own blog post, so we’ll just briefly touch upon it. We broadly classify the problem into layers: (1) hardware & OS, (2) Kubernetes core (e.g. API server, controllers and kubelets), (3) add-ons (e.g. SkyDNS & ServiceLoadbalancer) and (4) applications. We are currently focused on layers 1-3. A major source of issues we’ve seen is add-on failures. If either DNS or the ServiceLoadbalancer reverse http proxy (soon to be upgraded to an Ingress Controller) fails, application services will start failing. One way we detect such failures is by monitoring the components using the Kubernetes API itself, which is proxied into the SaaS controller, allowing the PMK support team to monitor any cluster resource. To detect service failure, one metric we pay attention to is pod restarts. A high restart count indicates that a service is continually failing.Future topicsWe faced complex challenges in other areas that deserve their own posts: (1) Authentication and authorization with Keystone, the identity manager used by Platform9 products; (2) Software upgrades, i.e. how to make them brief and non-disruptive to applications; and (3) Integration with customer’s external load-balancers (in the absence of good automation APIs).ConclusionPlatform9 Managed Kubernetes uses a SaaS-managed model to try to hide the complexity of deploying, operating and maintaining bare-metal Kubernetes clusters in customers’ data centers. These requirements led to the development of a unique cluster deployment and management architecture, which in turn led to unique technical challenges.This article described an overview of some of those challenges and how we solved them. For more information on the motivation behind PMK, feel free to view Madhura Maskasky’s blog post.–Bich Le, Chief Architect, Platform9
Quelle: kubernetes

da Agency

Weekly Roundup: Top 5 Most Popular Posts

This week, our readers enjoyed some big #Docker news, including the great milestone of making Docker 1.12, Docker for Mac and Docker for Windows generally available for production environments, answers to the ten most often asked Docker questions and more. As we begin a new week, let’s recap our top 5 most-read stories for the week of July 24, 2016:

1. Docker 1.12 Goes GA: Docker 1.12 adds the largest and most sophisticated set of features into a single release since the beginning of the Docker project.
2. Docker for Mac and Windows: Native development environment using hypervisors built into each operating system. (No more VirtualBox!)
3. Docker Questions: The ten most common Docker questions (and answers) asked by IT Admins.
4. Function as a Service: The Function-as-a-Service model and how to generate a function from an image on Docker hub via Chanwit Kaewkasi
5. 12 Factor Method: Using the twelve factors application to Dockerize Apps via Rafael Gomes

Top 5 Docker Posts — July 24, 2016 via @DockerClick To Tweet

Quelle: https://blog.docker.com/feed/

da Agency

Announcing Docker 1.12 Hackathon winners

The judges have deliberated, our community has voted, and the results are in! We are happy to announce the top 5 submissions of the Docker 1.12 Hackathon.
In case you missed it, the theme of the hackathon was to build, ship, and run a distributed software application using a release candidate of Docker 1.12. We encouraged participants to hack the new features included in Docker 1.12, such as: Swarm Mode, Cryptographic node identity, Service API, and Build-in routing mesh.

A big thank you to our judges (below) for taking the time to review all the submissions! 

Phil Estes – Docker Captain and Senior Technical Staff Member at IBM Cloud Open Technologies
Arun Gupta – Docker Captain and VP of Developer Relations at Couchbase
Laura Frank – Docker Captain and Senior Engineer at Codeship
Mano Marks – Director of Developer Relations at Docker
Mike Coleman – Technical Evangelist at docker

 

Each of the judges rated the submissions from 1 &8211; 5 stars based on the following criteria:

Fit &8211; Does Docker improve the project or fundamentally enable it?
Efficiency &8211; Is this implementation small in size, easy to transport, quick to start up and run?
Integration &8211; Does the project fit well into other systems, or is it sufficiently complex itself to be its own system?
Transparency &8211; Can other people easily recreate your project now that you’ve shown how? Is your code open source?
Presentation &8211; How well did you present your project in the video? Does the video convey your hack clearly and do you cover all the important points?
Usefulness &8211; Popular vote on how many would people would use your hack. So keep your audience in mind!
Longevity &8211; Can the project be improved / built upon?
Bonus Point! &8211; If the submission included contributions and bug fixes to the Docker 1.12 Github repository your final score will be allotted one extra point

The Winners:
1st Place
Authors: Marcos Nils, Jonathan Leibiusky and Jimena Tapia
Title: Whaleprint
What does it do?: Whaleprint makes possible to use your current DAB files as swarm mode blueprints and will show you with extreme detail exactly which and how your services will be deployed/removed. At the same time it will also handle service update diffs describing precisely what things will change and what will be their new updated value.
Features:

Preview and apply your DAB changesets
Extend the current DAB format to support MOAR features.
Manage multiple stacks simultaneously
Fetch DAB&8217;s from an URL
Remove and deploy service stacks entirely
Allow to apply specific service update through the &8211;target option
Outputs relevant computed stack information like Published ports
Alternatively print complete plan detail instead of changesets only

Built With: golang, apis, Swarmkit

Prize: MakerBot – Replicator Mini as well as five Docker Hub private Repositories and one Docker Cloud extra node.

 
2nd Place
Authors: Weston McNamee and Stephen Bunn
Title: Swarm CI
What does it do?: SwarmCI is CI extension as well as (future) a stand-alone CI/CD platform. You can use SwarmCI to extend an existing CI system (Bamboo, TeamCity, Jenkins, etc) with a few steps:
1. Setup a Docker Swarm.
2. Converting existing build tasks, stages, and jobs to a single .swarmci file.
3. Configure a single task in your build to run a single command to delegate work to your Docker Swarm: python -m swarm
Features: SwarmCI solves many of the problems found in conventional CI/CD platforms.

Build tasks are run within a docker container, the image of which provided by the user, completely isolated from build agent and the rest of the host. In addition, the starting state of a build does not change between builds, as containers aren&8217;t reused.
The Docker image in which tasks are run within is provided by the user, thus, it can be completely customized. Never wait for an idle agent that has your requirements, or for the OPS team to configure an agent with new requirements for you.
Resource waste id decreased because builds run on the Swarm. As long as a node on the Swarm has the available CPU/Memory requirements for your build, your build runs. Scale your Swarm up/down to keep waste to a minimum.
With the SwarmCI as a extension, you can get isolated, distributed, parallel build tasks without sacrificing the use of additional build agents.

Prize : Apple Watch
 

 
3rd Place
Authors: Chris Crone, Quentin Hocquet and Matthieu Nottale
Title: Infinit
What does it do?: aggregates the local storage of each Docker Swarm node and provides a shared volume that can be mounted by any Docker service to make it stateful. As nodes are added/removed, the storage rebalances and scales automatically as expected ensuring availability and increased capacity.
 

Prize: 3rd place: Oculus Rift

4th Place
Authors:  Shrikrishna Holla and Akram Rameez
Title: dq &8211; Task Scheduler for Docker Functions
What does it do?: dq is a task Scheduler for Docker Functions. DQ is an amalgamation of the best features of a job scheduler like resque and a serverless platform like AWS lambda. It is meant to be self-hosted and called using REST APIs. All tasks run on docker containers defined in a spec similar to compose called dq.yml.
Features:

Call a background task with arguments [Ex: sending email]
Schedule a recurring task [Ex: backing up db]
Run a background service that handles HTTP requests and auto scales based on load [voting, spam checking]

Built With: javascript
VIDEO:

 

 
5th Place
Author: Wendy-Anne Daniel
Title: nginx webservices
What does it do?: It provides all the security testing tools via the metasploit framework, scapy, sully etc. on multiple Linux OS on multiple containers as well as the attack surfaces to try out exploits in a self-contained environment. With docker 1.12, they are turned into simple and complex services with interservice communication.

Prize: Docker swag
Congratulations to our winners and thank you to everybody who participated. You can congratulate the winners and check out the awesome submissions in the Docker 1.12 Hackathon gallery.  
Don’t stop coding just because the competition is over! Update your portfolio to inform your followers about new projects and get feedback from fellow hackers.

The results are in! Announcing the winners of the @Docker 1.12 Hackathon! #dockerhackClick To Tweet

Quelle: https://blog.docker.com/feed/