BoxBoat Blog

Service updates, customer stories, and tips and tricks for effective DevOps

Building Containers with Kubernetes and Knative

Building Containers with Kubernetes and Knative

by Cole Kennedy | Friday, Aug 10, 2018 | Kubernetes

Developing for Kubernetes can be a daunting task for any developer not familiar with the ecosystem. The developer needs to understand how to create spec files, author CI/CD scripts with a system such as Jenkins or CircleCI, and instrument logging and tracing. Knative aims to solve some of these issues, abstracting the details of building images away from the developer. Knative helps developers build, deploy, and manage modern serverless workloads on Kubernetes.

BoxBoat Joins CNCF as Silver Member

BoxBoat Joins CNCF as Silver Member

by Will Kinard | Monday, Jul 30, 2018 | Kubernetes News

BoxBoat is proud to announce our newest committment to delivering the best available container enablement services to our clients. We strive to hire and retain only the best of the best as BoxBoat team members; joining the Cloud Native Computing Foundation as a Silver Kubernetes Certified Service Provider recognizes this expertise. We are excited to continue our training, experience, and contribution to the Kubernetes community, as well as to our clients, with the support of the CNCF.

Docker EE Federation

Docker EE Federation

by Will Kinard | Wednesday, Jul 18, 2018 | Docker News

While our minds have already shifted ahead to Dockercon Europe, there was one announcement in particular from Dockercon2018 that everyone should take notice. Docker Enterprise Edition (EE) will soon allow organizations to federate applications across not only other deployments of itself, but accompanying Kubernetes cloud-hosted solutions like AWS Elastic Container Service for Kubernetes (EKS), Google Kubernetes Engine (GKE), and Azure Kubernetes Service (AKS). This pivotal business decision for Docker Inc. demonstrates that they are listening to their customers and should allow them to continue to be the go-to container platform for enterprises across the globe.

GitOps Kubernetes Rolling Update when ConfigMaps and Secrets Change

GitOps Kubernetes Rolling Update when ConfigMaps and Secrets Change

by Caleb Lloyd | Thursday, Jul 5, 2018 | Kubernetes

The Kubernetes ConfigMap resource is used to mount configuration files into pods. The Kubernetes Secret resource is used to mount secret files into pods. Both of these resources are commonly used when deploying a GitOps Configuration as Code workflow.

ConfigMap and Secret files inside of containers are updated automatically when the underlying ConfigMap or Secret is updated. If an application reads a ConfigMap or Secret value on startup, it may have a stale configuration after a ConfigMap or Secret is updated.

One approach for dealing with this is to add application logic to watch ConfigMap and Secret files for changes, and reconfigure the application on the fly. This can lead to complicated logic since objects using the old configuration will need to be detected and recreated.

Another approach is to trigger a rolling update of the Deployment when it’s dependent ConfigMaps and Secrets are updated. This blog post describes a solution that creates ConfigMaps and Secrets alongside a Deployment, and uses a hash of these resources to automatically trigger a rolling update if they have changed.

Kubernetes NGINX Ingress TLS Secrets in All Namespaces

Kubernetes NGINX Ingress TLS Secrets in All Namespaces

by Caleb Lloyd | Monday, Jul 2, 2018 | Kubernetes

Kubernetes Ingress is a powerful resource that can automate load balancing and SSL/TLS termination. The NGINX Ingress Controller is currently the only supported cloud-agnostic ingress controller for Kubernetes. A single ingress controller can be deployed to the cluster and service requests for all namespaces in a cluster. There is currently an outstanding issue where Ingress resources can only reference TLS secrets within their own namespace:

This can be a problem when a cluster has a wildcard certificate that needs to be used across multiple ingress resources in different namespaces. A prime example is a cluster that is setup to automatically request Let’s Encrypt wildcard certificates. In this blog post, we explain an approach for automatically reflecting TLS secrets to every namespace in the cluster.

  Page 1 of 11   Older Posts