Ratnadeep Debnath

Containers are great in terms of application packaging and delivery, but there’s a lot of noise in the space. But when it comes to multi-container applications, most production setups use advanced container orchestration technologies like Kubernetes, Openshift, Mesos/Marathon, which are not that developer friendly.

Developers prefer docker-compose for its simplicity. This talk will showcase our ongoing efforts at Red Hat, Skippbox and Google to bridge this gap between deploying containers in development to production, and the need to standardize a multiple container definition spec which works seamlessly across different environments and container orchestration platforms.

Containers are everywhere now a days. We want to use containers during development, in staging, in production, etc. However, it’s not that straight forward, thanks to the plethora of container runtimes and toolchains. Some are developer friendly, whereas, others, which are battle tested for production, are not that developer friendly. In this talk we’ll walk you through the current state of things for containers in various environments: development, production, etc., the disparity between container technologies usually used in development and production, how to take things from development to production, etc. This will showcase how Red Hat, Skippbox and Google have been working to solve this problem, and the result of that work is a CLI tool called Kompose, https://github.com/skippbox/kompose. Kompose takes in docker-compose file format and generates Kubernetes and OpenShift artifacts. However, is it enough? We need a standardized specification to define multi container applications that works seamlessly across multiple container runtimes and orchestration tools.

This talk will be organized as follows:

Developer workflow with containers Container technologies preferred in production What it takes to have a production like environment for development? So much to learn! Pushing application to production with 0 (or little) learning curve Kompose: Tool to move from docker-compose to Kubernetes What next? A standard specification to define multi-container application Road to container Utopia

ircb, or IRC Bouncer, is an attempt to make next gen IRC bouncer as a service, from the ground up. It focuses on: - easy setup, deployment, management - low barrier and automated entry point for users - handle scale: - support multiple nodes to distribute connections to IRC networks - load balance client connections - optimize network IO usage, by using intelligent caching - support multiple client connections for the same connection to IRC network

Source code: https://github.com/waartaa/ircb/ Design doc: https://github.com/waartaa/ircb/wiki/Design-docs

ircb1 is a IRC Bouncer as a service, made for humans. It's currently functional as a basic IRC bouncer, however, unlike mainstream IRC bouncers, it supports multiple client connections for the same IRC network connection for a user. It aims to provide a scalable bouncer service along with easy setup, deployment and management. It also envisions to provide a low barrier entry point for users, where users can join and start using the service in an automated fashion, without going through manual processes.

Although, ircb is a standalone product, it is also one of the core components of waartaa2. waartaa is our attempt to create an open source SAAS communication and collaboration tool, around IRC. We also participated in GSoC under the Fedora umbrella. However, we hit various roadblocks with the initial code base given to it's monolithic structure. So, we started breaking down the app into micro services. Thus, ircb, the scalable IRC bouncer to empower waartaa, was born.

IRC networks limit the number of connections for an IP, and this limit has to be manually negotiated, and the process takes time. We came to know of this during maintaining a demo instance of waartaa on a single node, when Freenode will stop rejecting IRC connections from our IP. That's why we are looking forward to have a multi node model for ircb, where we can intelligently distribute the IRC network connections, as needed. We are also brainstorming to figure out an intelligent way to load balance connections from IRC clients to the bouncer service in a stateless fashion. You can find some insight about it in our initial design docs3. We are also trying to develop a reactive store layer to empower realtime applications, in our case, waartaa.

We want to showcase our project to the intelligent folks present at FOSDEM with the hope of getting valuable feedback and contributors.