Kategorie: Kubernetes

Docker at Tech Field Day 2016

Save the date!  This coming Thursday Docker is excited to host the delegates of Cloud Field Day at our headquarters for a deep dive into the Docker platform. Cloud Field Day is part of a series of Tech Field Day events that bring together technology companies and IT thought leaders to talk shop with technology and insights.
Cloud Field Day will be live and in person at Docker HQ but anyone can join in by participating in the live stream. Docker will be featured at 1pm on Thursday Sept 15th. Join us by visiting the Cloud Field Day event page.
Cloud field day is just one in a series of Tech Field Day sessions coordinated by IT industry veterans Stephen Foskett and Tom Hollingsworth. Learn more about the whole Tech Field Day series here.
 
ICYMI:  Our very own Mike Coleman, spoke at the Tech Field Day Express at VMworld.  In this one hour session, Mike walked a group of vExperts through an introduction to containers, what the new end to end application workflow looks like and an overview of Docker 1.12 with built in orchestration.
 
Intro to Docker

Build, Ship, Run with Docker

Docker 1.12 with built in Orchestration

See you online!

Join us for the Cloud Field Day live stream
Read the ebook: Docker for the Virtualization Admin
Learn more about Docker Datacenter
Try Docker Datacenter free for 30 days

The post Docker at Tech Field Day 2016 appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Creating a PostgreSQL Cluster using Helm

Editor’s note: Today’s guest post is by Jeff McCormick, a developer at Crunchy Data, showing how to deploy a PostgreSQL cluster using Helm, a Kubernetes package manager.Crunchy Data supplies a set of open source PostgreSQL and PostgreSQL related containers. The Crunchy PostgreSQL Container Suite includes containers that deploy, monitor, and administer the open source PostgreSQL database, for more details view this GitHub repository. In this post we’ll show you how to deploy a PostgreSQL cluster using Helm, a Kubernetes package manager. For reference, the Crunchy Helm Chart examples used within this post are located here, and the pre-built containers can be found on DockerHub at this location. This example will create the following in your Kubernetes cluster:postgres master servicepostgres replica servicepostgres 9.5 master database (pod)postgres 9.5 replica database (replication controller)This example creates a simple Postgres streaming replication deployment with a master (read-write), and a single asynchronous replica (read-only). You can scale up the number of replicas dynamically.ContentsThe example is made up of various Chart files as follows:values.yamlThis file contains values which you can reference within the database templates allowing you to specify in one place values like database passwordstemplates/master-pod.yamlThe postgres master database pod definition.  This file causes a single postgres master pod to be created.templates/master-service.yamlThe postgres master database has a service created to act as a proxy.  This file causes a single service to be created to proxy calls to the master database.templates/replica-rc.yamlThe postgres replica database is defined by this file.  This file causes a replication controller to be created which allows the postgres replica containers to be scaled up on-demand.templates/replica-service.yamlThis file causes the service proxy for the replica database container(s) to be created.InstallationInstall Helm according to their GitHub documentation and then install the examples as follows:helm initcd crunchy-containers/examples/kubehelmhelm install ./crunchy-postgresTestingAfter installing the Helm chart, you will see the following services:kubectl get servicesNAME              CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGEcrunchy-master    10.0.0.171   <none>        5432/TCP   1hcrunchy-replica   10.0.0.31    <none>        5432/TCP   1hkubernetes        10.0.0.1     <none>        443/TCP    1hIt takes about a minute for the replica to begin replicating with the master. To test out replication, see if replication is underway with this command, enter password for the password when prompted:psql -h crunchy-master -U postgres postgres -c ‘table pg_stat_replication’If you see a line returned from that query it means the master is replicating to the slave. Try creating some data on the master:psql -h crunchy-master -U postgres postgres -c ‘create table foo (id int)’psql -h crunchy-master -U postgres postgres -c ‘insert into foo values (1)’ Then verify that the data is replicated to the slave:psql -h crunchy-replica -U postgres postgres -c ‘table foo’You can scale up the number of read-only replicas by running the following kubernetes command:kubectl scale rc crunchy-replica –replicas=2It takes 60 seconds for the replica to start and begin replicating from the master.  The Kubernetes Helm and Charts projects provide a streamlined way to package up complex applications and deploy them on a Kubernetes cluster.  Deploying PostgreSQL clusters can sometimes prove challenging, but the task is greatly simplified using Helm and Charts.–Jeff McCormick, Developer, Crunchy DataDownload KubernetesGet involved with the Kubernetes project on GitHub Post questions (or answer questions) on Stack Overflow Connect with the community on SlackFollow us on Twitter @Kubernetesio for latest updates
Quelle: kubernetes

Deploying to Multiple Kubernetes Clusters with kit

Editor’s note: today’s guest post is by Chesley Brown, Full-Stack Engineer, at InVision, talking about how they build and open sourced kit to help them to continuously deploy updates to multiple clusters.Our Docker journey at InVision may sound familiar. We started with Docker in our development environments, trying to get consistency there first. We wrangled our legacy monolith application into Docker images and streamlined our Dockerfiles to minimize size and amp the efficiency. Things were looking good. Did we learn a lot along the way? For sure. But at the end of it all, we had our entire engineering team working with Docker locally for their development environments. Mission accomplished! Well, not quite. Development was one thing, but moving to production was a whole other ballgame.Along Came KubernetesKubernetes came into our lives during our evaluation of orchestrators and schedulers last December. AWS ECS was still fresh and Docker had just released 1.9 (networking overlay release). We spent the month evaluating our choices, narrowing it down to native Docker tooling (Machine, Swarm, Compose), ECS and Kubernetes. Well, needless to say, Kubernetes was our clear winner and we started the new year moving headlong to leverage Kubernetes to get us to production. But it wasn’t long when we ran into a tiny complication…Automated Deployments With A CatchHere at InVision, we have a unique challenge. We just don’t have a single production environment running Kubernetes, but several, all needing automated updates via our CI/CD process. And although the code running on these environments was similar, the configurations were not. Things needed to work smoothly, automatically, as we couldn’t afford to add friction to the deploy process or encumber our engineering teams.Having several near duplicate clusters could easily turn into a Kubernetes manifest nightmare. Anti-patterns galore, as we copy and paste 95% of the manifests to get a new cluster. Scalable? No. Headache? Yes. Keeping those manifests up-to-date and accurate would be a herculean (and error-prone) task. We needed something easier, something that allows reuse, keeping the maintenance low, and that we could incorporate into our CI/CD system.So after looking for a project or tooling that could fit our needs, we came up empty. At InVision, we love to create tools to help us solve problems, and figuring we may not be the only team in this situation we decided to roll up our sleeves and created something of our own. The result is our open-source tool, kit! (short for Kubernetes + git)Hello kit!kit is a suite of components that, when plugged into your CI/CD system and source control, allows you to continuously deploy updates (or entirely new services!) to as many clusters as needed, all leveraging webhooks and without having to host an external service.Using kit’s templating format, you can define your service files once and have them reused across multiple clusters. It works by building on top of your usual Kubernetes manifest files allowing them to be defined once and then reused across clusters by only defining the unique configuration needed for that specific cluster. This allows you to easily build the orchestration for your application and deploy it to as many clusters as needed. It also allows the ability to group variations of your application so you could have clusters that run the “development” version of your application while others run the “production” version and so on.Developers simply commit code to their branches as normal and kit deploys to all clusters running that service. Kit then manages updating the image and tag that is used for a given service directly to the repository containing all your kit manifest templates. This means any and all changes to your clusters, from environment variables, or configurations to image updates are all tracked under source control history providing you with an audit trail for every cluster you have.We made all of this Open Source so you can check out the kit repo!Is kit Right For Us?If you are running Kubernetes across several clusters (or namespaces) all needing to continuously deploy, you bet! Because using kit doesn’t require hosting any external server, your team can leverage the webhooks you probably already have with github and your CI/CD system to get started. From there you create a repo to host your Kubernetes manifest files which tells what services are deployed to which clusters. Complexity of these files is greatly simplified thanks to kit’s templating engine.The kit-image-deployer component is incorporated into the CI/CD process and whenever a developer commits code to master and the build passes, it’s automatically deployed to all configured clusters.So What Are The Components?kit is comprised of several components each building on the next. The general flow is a developer commits code to their repository, an image is built and then kit-image-deployer commits the new image and tag to your manifests repository. From there the kit-deploymentizer runs, parsing all your manifest templates to generate the raw Kubernetes manifest files. Finally the kit-deployer runs and takes all the built manifest files and deploys them to all the appropriate clusters. Here is a summary of the components and the flow:kit-image-deployerA service that can be used to update given yaml files within a git repository with a new Docker image path. This can be used in collaboration with kit-deploymentizer and kit-deployer to automatically update the images used for a service across multiple clusters.kit-deploymentizerThis service intelligently builds deployment files as to allow reusability of environment variables and other forms of configuration. It also supports aggregating these deployments for multiple clusters. In the end, it generates a list of clusters and a list of deployment files for each of these clusters. Best used in collaboration with kit-deployer and kit-image-deployer to achieve a continuous deployment workflow.kit-deployerUse this service to deploy files to multiple Kubernetes clusters. Just organize your manifest files into directories that match the names of your clusters (the name defined in your kubeconfig files). Then you provide a directory of kubeconfig files and the kit-deployer will asynchronously send all manifests up to their corresponding clusters.So What’s Next?In the near future, we want to make deployments even smarter so as to handle updating things like mongo replicasets. We also want to add in smart monitoring to further improve on the self-healing nature of Kubernetes. We’re also working on adding additional integrations (such as Slack) and notification methods. And most importantly we’re working towards shifting more control to the individual developers of each service by allowing the kit manifest templates to exist in each individual service repository instead of a single master manifest repository. This will allow them to manage their service completely from development straight to production across all clusters.We hope you take a closer look at kit and tell us what you think! Check out our InVision Engineering blog for more posts about the cool things we are up to at InVision. If you want to work on kit or other interesting things like this, click through to our jobs page. We’d love to hear from you!–Chesley Brown, Full-Stack Engineer, at InVision.Download KubernetesGet involved with the Kubernetes project on GitHub Post questions (or answer questions) on Stack Overflow Connect with the community on SlackFollow us on Twitter @Kubernetesio for latest updates
Quelle: kubernetes