Part 2: Let’s go with containers
This is the second of six articles about how an IoT project with certain constraints and prerequisites was implemented. This time it is about trying to create windows containers with a massive setup of a proprietary piece of software.
- Part 1: Analysis & Design
- Part 2: (this one) Let’s go with containers
- Part 3: What about alternative deployment options?
- Part 4: Going on with alternative deployment options
- Part 5: Final architecture & learnings
How to host that?
Sure containers as hyped as useful. Putting everything in containers seems to be quite natural. Why sticking to anything else? Let’s have a look onto the advantages though:
Portability between different platforms and clouds—it’s truly write once, run anywhere.
Efficiency through using far fewer resources than VMs and delivering higher utilization of compute resources
Agility that allows developers to integrate with their existing DevOps environment.
Higher speed in the delivery of enhancements. Containerizing monolithic applications using microservices helps development teams create functionality with its own life cycle and scaling policies.
Improved security by isolating applications from the host system and from each other.
Faster app start-up and easier scaling.
Flexibility to work on virtualized infrastructures or on bare metal servers
Easier management since install, upgrade, and rollback processes are built into the Kubernetes platform.
That all sounds great. The first point is actually partly untrue at least for windows containers, there are prerequisites. Anyway, let’s have a look onto Azure services and pick the right one for our task. What is available for hosting, deployment, maintenance of containers and which one is the best choice?
Hosting choices on Azure for containers
|IF YOU WANT TO||USE THIS|
|Simplify the deployment, management, and operations of Kubernetes||Azure Kubernetes Service (AKS)|
|Quickly create powerful cloud apps for web and mobile||App Service|
|Easily run containers on Azure without managing servers||Container Instances|
|Cloud-scale job scheduling and compute management||Batch|
|Develop microservices and orchestrate containers on Windows or Linux||Service Fabric|
|Store and manage container images across all types of Azure deployments||Container Registry|
|Run fully managed OpenShift clusters, jointly operated with Red Hat||Azure Red Hat OpenShift|
AKS: Does it make sense to use AKS for at least three types of containers? Even if it is necessary to have a lot of instances, it seems to be some kind of overengineering. As I cannot estimate how many containers instances I need, I am unsure if the complexity of an AKS is going to pay out.
App Service: The only container instance that probably could have an http endpoint is the scheduler. Reader and Writer are unattended and work via messages, so no need. Actually it is possible to host containers, but if you don’t have an http endpoint, health probes will fail. That means, the container is going to be restarted as App Service „thinks“ the container is unresponsive. This is something I learned later.
Container Instances: Had a short look. This sounds promising esp. due to the early stage of implementation. With a container registry, automatic deployment is possible, I do not need to care about network, ingest, security within an AKS. So let’s go with this service.
Batch: Actually I didn’t see this service when I started the implementation. Would have been a good idea at least to replace the scheduler. Not sure about the compute capabilities. I’ll have a look onto this service in a later project.
Service Fabric: I used Service Fabric some years before. Still 30% of all Azure services run on Service Fabric, so don’t underestimate the power and flexibility of this framework. You know, great power comes with great responsibility. Service Fabric is as AKS too complex for this simple solution. For production system, at least 5 nodes are necessary, definition and running services is specific and need a lot of configuration.
Container Registry: Sure, I need it :-).
Open Shift: Always wanted to try OpenShift, but for this project it doesn’t seem to be the right choice to go into „testing mode“. Actually customer pays and this kind of eval is not included, unluckily.
Windows containers, pure fun
For creation of a windows container, I need a windows environment. I do work on a mac, so I got a VM in our data center for doing. This is Windows Server 2016. Is that a good idea? I am not sure.
Let’s start with the more simple Docker file definition. asp.net core can run pretty much everywhere and it isn’t as large as the actual windows server core image. Looks like this.
The first time I started with Docker on Windows is long ago. I remembered having no fun at all. Have a look on Docker containers on Windows Server 2016 with Containers: HNS failed with error: Unspecified error orDocker containers on Windows 10: HNS failed with error : Unspecified error. Experiencing these issue had been on a physical machine, but that doesn’t make too much difference. I tried the same solutions, firstly, switch off the virus scan. Working in a large company means, this can take days for a small time window where I can check if it is the cause.
Switching off the virus scan solved the problem with downloading, but still it was not possible to create docker images. It always failed somewhere in the middle with Access Denied error messages as well. What does it mean?
Windows Server 2016 is unreliable for creating Docker images
Lots of things are processualized within large companies. Ugrading the image took days. But here we go, I finally was able to create the image for the Writer component. All fine.
.net Framework, Containers and a massive setup
Pretty optimistic me, I searched the internet and thought:
Come on, cannot be that hard to create a docker image for a .net framework lib!
I did what all guys do: I used my Google Fu to find the right thing. I thought I was successful, when I saw a docker image definition for the AFSDK lib of OSISoft. This is how the Dockerfile looks like.
Uh, pretty scary. Powershell. Setups. Ah, come on. Will work. In his explanation the guy stated, this is what is going to be needed:
To be honest, that sounds odd. Weird. I’ll find more adjectives.
Anyway, I need to have it in place, so I followed instructions. Having a windows 2019 server at least creation of docker images worked. And then I spent a lot of time on running this setup. It is not my perferred way of creation of Docker containers to have
- a zip file that needs to be copied
- then unzipped
- installed via weird setup.ini file that is as long as the Bible
- not seeing anything as a result in terminal. Setup just finishes with „success“ or „failed“.
- It is necessary to open the log to get the details.
Executing windows setups is pure love inside of docker containers (warning: Ironic mode)
Isn’t it funny when a setup tells you, it wants to restart the „machine“ when being installed in a docker container?
Have a look onto the setup.ini
The setup needs to run silently. In Docker containers I wont be able to accept dialogs so double check the ini file. Let’s have a look. It’s massive.
Are these guys kidding? Millions of options. Actually I could have used that face from Jim Carrey all over the place. Sometimes it is good that webcam doesn’t capture the face when doing this weird stuff.
At least some comments in that file! You can imagine, I checked a lot of variations:
- which ones are necessary for the program to work correctly?
- how can I prevent the setup’s demand for restarts?
- where are restarts probably necessary? This is maybe necessary for installing .net 4.8. So get the right image and skip this installation… and so on.
Finally I arrived with this definition of the setup.ini:
I really spent a lot of time.
Implementing the functionality was done in 1.5 weeks. Doing the infrastructure automation took already two days and was completely unsatisfying.
I didn’t make it. There was always a weird error message in setup logs, that was not understandable. I had been pretty creative. Lots of variations. When it takes to much time…
When consuming too much time for a task it looks like you need help
So I contacted the support of OSISoft asking for a docker image from the provider. This was pretty interesting and more a political than a technical issue. OSISoft already has a REST-based Http interface in place that can be used for the same reasons. And I would have loved to use that. But it generates a lot of costs, so it was not feasible to switch to http. God, this would have been eased everything, also the implementation. Anyway.
I always tough times, when I need to confess that something doesn’t work. I tend to spend even more time. Try to kill the issue with more time and effort. Sometimes that does work, but mostly it doesn’t. And then I even spend more time.
It is like to spend money on a project that it is known it is doomed to fail but because there had been an investment it is hard to stop
Okay, change direction. Docker will not work with .net Framework and this massive old-school setup. Let’s have another look onto different options in the next article.
How can .net framework be hosted?
- Cloud Services
- Service Fabric
- Windows Service on a VM
All not the options I wanted, but life’s hard. Follow me to the next one. Even darker.