As of version 1.6.3, Rancher introduced the Role-Based Access Control (RBAC) feature in Kubernetes. This feature allows admins to configure different policies that allow or deny access for users and service accounts to Kubernetes API resources.
To better understand how the RBAC feature works, this post will shed light on how authentication works with the Kubernetes API, and how the RBAC authorization module works with authenticated users. Read more
Recently, I moved to New York City. As a new resident, I decided to take part in the NYC DeveloperWeek hackathon, where our team won the NetApp challenge. In this post, I’ll walk through the product we put together, and share how we built a CI/CD pipeline for quick, iterative product development under tight constraints.
The Problem: Have you ever lived or worked in a building where it’s a pain to configure the buzzer to forward to multiple roommates or coworkers? Imagine that a friend arrives and buzzes your number, which is set to forward to your roommate who is visiting South Africa, and has no cell service. If you’re running late, your friend is just stuck outside.
The Product: We built a PBX-style application that integrations with Zang, and forwards a buzzer to multiple numbers, and even allows your friend to use a PIN on his phone to gain entry.
The constraint: For the hackathon, we had to use hardware that had already been setup and allocated.
Building our Hackathon CI/CD Pipeline
Our newly-updated eBook walks you through incorporating containers into your CI/CD pipeline. Download today!
For the competition, we knew that we wanted our builds scalable from the start, and that each deployment would snapshot our entire data environment pre-deployment using NetApp ONTAP (a sponsor of the Hackathon, and a really nice group of folks); if any deployment had an issue, we could simply and quickly roll back.
Fortunately, I am a firm believer in building stateless, Docker container-ready, rebuildable architecture; I can’t go back to the world that existed before: no real CI/CD, lots of SSH-ing into other systems, or SCP-ing data from one place to another. Thankfully, today we have tools and strategies that can help us.
When deploying applications in the container world, one of the less obvious points is how to make the application available to the external world, outside of the container cluster. One option is to use the host port, which basically maps one port of the host to the container port where the application is exposed. While this option is fine for local development, it is not viable in a real cluster with many applications deployed. One solution is to use an HTTP proxy/load balancer. This container will be exposed using standard HTTP/HTTPS ports on the host, and will route traffic to the application running as a container.
In this post, we will setup Traefik as an HTTP proxy / load balancer for web services running in a Rancher Cattle setup. Traefik will dynamically update its configuration using the Rancher API. An SSL wildcard cert will be used. The (nice) Let’s Encrypt ACME feature Traefik is offering will not be used here. We will make use of Rancher secret feature. If you plan to use Traefik with Let’s Encrypt SSL certs, I encourage you to use the Traefik stack available in Rancher Community Catalog.
containerd is an industry-standard core container runtime that was initially released by Docker Inc. in December 2015 and contributed to CNCF in March 2017. We’ve received a number of questions about the project, so I thought I would provide you my perspective as well as some preliminary thoughts on how how Rancher Labs will leverage it.
Docker, Kubernetes, and containerd
The containerd project represents an important step in the evolution of the Docker platform. In the beginning, the Docker engine was quite simple. It merely consisted of the minimum support required to run Docker images on a single host. Over the last few years, however, the Docker Engine has evolved significantly. The Docker engine now includes sophisticated support for cluster management, multi-host networking, and scheduling. Today, Docker is actually closer to a platform like Kubernetes, even though Kubernetes was created to manage Docker. Read more
GitLab is, at its core, a tool for centrally managing Git repositories. As one might expect form a platform that provides this service, GitLab provides a robust authentication and authorization mechanism, groups, issue tracking, wiki, and snippets, along with public, internal, and private repositories.
GitLab goes further by including a powerful continuous integration (CI) engine and a Docker container registry, allowing you to go from development to release inside of the same utility. It continues by adding two more powerful open source software utilities: Prometheus for monitoring, and Mattermost for team communication. The platform has a solid API and integrates with existing third-party systems like JIRA, Bugzilla, Pivotal, Slack, HipChat, Bamboo, and more.
All of this begs the question: why use GitLab instead of using SaaS services directly? The answer lies in personal taste. For most people, paying SaaS providers for the services that they provide is an excellent solution. You can focus on building your application and let them worry about maintaining the tools. What if you already have infrastructure with spare capacity? What if you just want private repositories without paying for that privilege? What if you did the math and determined that you can save money by hosting it yourself? What if you just want to own your own data?
Bringing services in-house opens you up to the risk of spending more time managing them and getting them to talk to each other, which is why GitLab truly shines as an option. With one click and a few minutes of configuration, you can be up and running with a complete solution.
One of the great benefits of the Rancher container management platform is that it runs on any infrastructure. While it’s possible to add any Linux machine as a host using our custom setup option, using one of the machine drivers in Rancher makes it especially easy to add and manage your infrastructure.
Today, we’re pleased to have a new machine driver available in Rancher, from our friends at cloud.ca. cloud.ca is a regional cloud IaaS for Canadian or foreign businesses requiring that all or some of their data remain in Canada, for reasons of compliance, performance, privacy or cost. The platform works as a standalone IaaS and can be combined with hybrid or multi-cloud services, allowing a mix of private cloud and other public cloud infrastructures such as Amazon Web Services. Having the cloud.ca driver available within Rancher makes it that much easier for our collective users to focus on building and running their applications, while minding data compliance requirements. Read more