Yesterday, I did a live blogging post covering the Container Development Kit DevNation session. The CDK solves a fairly large problem, one that I have struggled with during my tenure as a Systems Administrator... giving developers a production-like environment. If you cannot tell, I'm a big fan of the CDK. It doesn't just give developers access to something approximating production, it also gives you an IDE combined with the tools to make you productive with the sandbox environment.
However, I have a confession to make-- I'm not a fan of GUI IDEs. In fact, I avoid them at all costs. To me, it doesn't get any better than writing perl in Vim. That is my happy place. I've tried many GUI IDEs over the years, including Eclipse, but they all take me out of the terminal. Regardless of the language, Python, Perl, Ruby; I find Vim makes me most productive. Of course, I also live in the woods and don't own a pair of skinny jeans, so take it for what it is worth.
The container development that I have done has all been from the command line. Lalatendu Mohanty, Praveen Kumar, and Navid Shaikh's session on $subject obviously excited me as being in my wheelhouse. Containers have enormous benefits, so anything to make the process any easier is a huge value.
In addition to the Eclipse integration, the CDK also gives you host command line access and vagrant ssh for connecting to the CDK VMs. Moreover, the CDK aims to provide the same experience across Windows, OS X and RHEL clients.
Much of the command line tooling provided by the CDK can be accessed via vagrant, which acts as glue between the CDK and user's development environment. For example:
- vagrant service-manager start/stop/restart {kubernetes, openshift, docker}
- vagrant service-manager env docker
- vagrant ssh #to access one of the VMs directly
You can use sync-folder with vagrant-sshfs for sharing data between the host machine and the CDK VMs. This solution allows for cross-platform consistency without using native OS tooling. This also help to save your work across resetting the CDK VMs while using native tooling within your host OS.
The CDK also ships with the Docker and oc binaries included within the CDK VMs. Of course, you can also install them directly on your host OS, which may make things a little easier.
You can create your Dockerfiles, container images, and so on using your traditional tool set, then us the vagrant tooling for creating and testing your images and containers. Once you are ready to deploy, there is a specific packaging standard that both OpenShift and Kubernetes support, called Nulecule. AtomicApp is the runtime that understands the Nulecule standard. OpenShift2Nulecule creates a Nulecule file with artifacts for running on OpenShift or Kubernetes.
In short, the CDK gives folks the tooling required to build your application, as well as the mechanisms to package, test and deploy it, all without leaving your workstation. As always, Red Hat is about choice and providing developers multiple options and tooling to get the job done, regardless of how you work.
Ecosystem Projects included as part of the CDK.
- vagrant-service-manager
- vagrant-sshfs
- adb-vagrant-registration
- adb-utils
- Landrush
- OpenShift2Nucle
You can download Red Hat Container Development Kit 2.1 from developers.redhat.com.
About the Author
Brian J. Atkisson is a Senior Principal Systems Engineer and the technical lead on the Red Hat IT Identity and Access Management team. He has 18 years of experience as a Systems Administrator and Systems Engineer, focusing on identity management, virtualization, systems integration, and automation solutions. He is a Red Hat Certified Architect and Engineer, in addition to his academic background in Biochemistry, Microbiology and Philosophy.
Last updated: February 6, 2024
