For developers and architects, the last few years have been truly amazing! I thought we reached a peak when I was able to use complex technologies—including a clustered database, queues, and topics—to build an event-based application over a weekend. Though the logic wasn’t complex, it was amazing to setup that infrastructure with just a right-click. Poof, it’s deployed to the cloud! Then I got the bill. For a sandbox environment, it was more than I wanted—or expected—to pay. Could I have written a Terraform or Ansible script to set it up and tear it down daily? Maybe, but I was just trying to validate a concept. Recently, I had a similar need to design a solution for an event-based system, but this time the solution needed to support on-premise and cloud.
By now, I have deployed several simple apps to my local Docker container, but these are all straightforward apps, based on examples from labs/courses I’ve taken. But not this time. This time there was no blueprint to follow. Because the blueprint was what I needed to create.
Getting started was easy: “docker pull <technology of choice>.” Within minutes, I had mongo, rabbitmq, kafka, sql, and a few other considered technologies up and running. My first lesson was to be sure I had my ports mapped and exposed externally.
$> docker run --name ocr-mongo -d -p 27017:27017 ocr.mongo $> docker run --link ocr-mongo:mongo -p 8081:8081 mongo-express
Note: You’ll soon need to update mongo-express to use environment variables instead of link, which has been deprecated.
By exposing ports externally, I was able to run code outside the container either from the command line or from my IDE of choice and connect to the product in the container (sql, rabbit, etc). In minutes I had a few dotnet core console apps publishing events and a node script listening and storing queued messages into mongo. I tested and compared kafka with rabbitMQ to see which I could connect to, as well as to determine which one met my needs around messaging. As a bonus, I didn’t even need to be connected to the internet. I could work from anywhere!
As the API and functionality solidified, I began moving my code from running in the IDE to running in containers. I was surprised at how easy it was to modify existing base Dockerfiles to get my node and dotnet apps running in containers. The most complicated part of the process was compiling the dotnet app, then the copy steps required to move the assets into another container to be deployed (see simple example below).
# Stage 1
FROM microsoft/aspnetcore-build AS builder # restore & publish …
# Stage 2
FROM microsoft/aspnetcore WORKDIR /app COPY --from=builder /app .
While I realize this isn’t a traditional use of Docker, it’s the one that worked for me. Further, it revealed to me the value and power of containers. Now that the application is working locally in my personal cloud, I’ll deploy it to the public cloud and test scaling the application using options like OpenShift and Azure Container Service (AKS).
So stay tuned for those results! And to learn more about deploying or automating containers on-premise or in the cloud, please check out our Cloud & Hybrid IT offerings, or contact me directly at firstname.lastname@example.org.
Managing Director, Presales