Decreasing developer ramp-up time with containers

Decreasing developer ramp-up time with containers

Dec 21, 2020
Decreasing developer ramp-up time with containers

This year's pandemic has dramatically changed how we work today, as well as the environment we work in. Businesses have also had to adjust how they conduct their day-to-day operations. Unfortunately, this has reduced the workforce in some areas and spread the workload to those remaining.

There's the rub

In agencies with many clients, a developer could be working across various toolsets and technology stacks, both old and new alike. Onboarding a developer to these projects is no trivial task. Ensuring that the correct tools, libraries, and SDKs are installed, as well as that they are using the correct versions for the project, can take days, sometimes weeks. We're in a time where businesses don't have the luxury to wait or extra money to spend on this ramp-up time.

A few years ago, I was part of such a project, and it took me two weeks, working alongside the solution architect, to get the solution to compile and run on my local machine. The process had been documented, but there are always gaps. And as the project grew, these gaps widened.

So, how can we bring the ramp-up time for developers down from days and weeks to hours?

Virtual machines to save the day

One idea I had tried early on in my development career was to create a virtual machine for every client. This virtual machine would contain all the specific tools needed to work on that particular clients' project. I would even store the client's source code on the virtual machine to make the solution as quick to get going as possible.

It seemed ideal until I went back to an older client's virtual machine and spent the next few hours applying updates. Also, as I grew in clients, the number of virtual machines I was using increased. As such, I quickly ran out of disk space.

It became too much of a hassle after a while, and I stopped using virtual machines altogether.

Containers to the rescue

A few years ago, I heard about this great new way to test and run applications. Ensuring how it ran on your local machine would be exactly the same as on another developer's machine or in the cloud on the production environment. This was containers.

Docker describes containers as "a standardized unit of software that allows developers to isolate their app from its environment, solving the it-works-on-my-machine headache."


Unlike virtual machines, which contain an entire copy of the operation system, containers share the OS with the host—they're much smaller and lighter than virtual machines. Using tools like Docker Desktop and Docker Compose, we can define our application services and configure multiple containers to run together.

%Begin Code Block%

# This image installs the Kentico EMS application and copies over files to necessary to provide

# a fully functional Kentico EMS instance. It is designed to be used in conjunction with the

# Docker compose file located here. https://github.com/OnyxPrime/kentico-ems-docker-poc 

 

FROM mcr.microsoft.com/windows/servercore/iis AS base

 

FROM base as iissite

# Enable IIS features on image

RUN powershell.exe Add-WindowsFeature web-server, web-webserver

RUN powershell.exe -NoProfile -Command Remove-Item -Recurse C:\inetpub\wwwroot\*

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-WebServerRole

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-WebServer

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-CommonHttpFeatures

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-HttpErrors

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-HttpRedirect

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-ApplicationDevelopment

RUN powershell.exe Enable-WindowsOptionalFeature -online -FeatureName NetFx4Extended-ASPNET45

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-NetFxExtensibility45

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-HealthAndDiagnostics

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-HttpLogging

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-LoggingLibraries

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-RequestMonitor

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-HttpTracing

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-Security

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-RequestFiltering

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-Performance

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-WebServerManagementTools

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-IIS6ManagementCompatibility

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-Metabase

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-ManagementConsole

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-BasicAuthentication

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-WindowsAuthentication

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-StaticContent

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-DefaultDocument

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-WebSockets

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-ApplicationInit

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-ISAPIExtensions

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-ISAPIFilter

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-HttpCompressionStatic

RUN powershell.exe Enable-WindowsOptionalFeature -Online -FeatureName IIS-ASPNET45

 

FROM iissite AS final

# Set working directory

WORKDIR /kentico    

# Copy Kentico EMS installer and installer configuration file to working directory.

COPY Kentico_12_0.exe .

COPY KenticoInstallationProfile.xml .

# Run Kentico EMS installer with provided configuration file

RUN Kentico_12_0.exe KenticoInstallationProfile.xml

# Change working directory and copy files from a previous installation to the EMS directory. Without these files,

# the EMS application will be a base installation without a SQL installation and user will be prompted to provide the

# SQL server name and database name to complete the installation when trying to access the admin portal. 

#WORKDIR /inetpub

#COPY /update .

%End Code Block%

Once a container image is created, it can be shared with new team members to get them up and running quickly. Containers also provide a consistent and stable environment to run tests on our applications due to their ability to be torn down and rebuilt quickly.

You can experience this in action with the containerized Kentico 12 environment. Instructions and Docker files can be found here.

One step further

But what if we could take this idea of running our applications a step further and add the ability to develop them from within the container? 🤯

That's exactly what the team at Microsoft did when they introduced the Remote-Containers extension for Visual Studio Code (VSCode). This extension allows VSCode to connect to a container and load the necessary extensions defined for the project, as well as provide a terminal window inside the container to build and run our application.

In addition, you're able to install specific versions of SDKs, CLIs, or any other utility needed to build and run your application. 

Limitations

Microsoft created several container images designed to be used with the Remote-Containers extension for various programming languages and frameworks, but unfortunately, they are all based on the Linux operating system. Therefore, if you're dependent on Windows for any reason, developing within containers is currently not an option for you.

It's worth mentioning that there are many Windows containers available for use. This limitation is only for developing within containers, not running an application from them.

In case you like, want, or must use the full version of Visual Studio, remote development is not an option for you. At the time of this writing, the Remote-Containers extension only exists for VSCode. Visual Studio provides a different implementation for running/debugging applications within a Docker container.

If your application has one part dependent on Windows and another with the ability to run cross-platform—like Kentico Xperience 13—then Remote-Containers might be an option for you.

Accelerate the process

Using containers to run your applications can quickly speed up the process of ramping-up developers on projects. And as your teams move to more modern development frameworks with the ability to run cross-platform, you can move toward containerizing the entire development environment.

In the upcoming months, we'll be diving deeper in to process of containerizing a more complex application, like Kentico Xperience 13, with a separate front end, back end, and database. And when Kentico Xperience Odyssey begins beta releases, we'll see just how easy it is to use Remote-Containers with a modern application.

More by this author