Lansweeper Web running as a Container
So, the initial idea of this project was to do what Lansweeper hasn’t done in years and try to modernize the Lansweeper solution by running parts of it in PAAS/SAAS environments.
Basically Lansweeper hasn’t updated their main installation for use in the Cloud, which means that:
- The database cannot be run on Azure SQL or SQL Managed Machine, only SQL VM, and the support has been asked by customers in 2018: https://community.lansweeper.com/t5/forum/migrate-lansweeper-sql-db-to-azure/m-p/35654
- The Scanning server doesn’t work properly in a container and is not supported: https://community.lansweeper.com/t5/forum/lansweeper-container/m-p/8946
- The Web interface can run in a container (see below) but it’s not supported
As such, I’ve decided to start with what I assume would have been the easiest part of the project: containerizing the Lansweeper Web component and running it in Azure Container Services integrated with the VNET where the rest of the components are running and with a load balancer in front to load balance the traffic.
The work started with the construction of the Windows Dockerfile, where I already hit an issue with Docker refusing to switch to Windows Containers… Guess we know how much they care about those?
That took a reinstall and the command
& $Env:ProgramFiles\Docker\Docker\DockerCli.exe -SwitchDaemon
to solve, and then I could start working on it!
(ignore the Activate Windows message, it’s a temporary VM I set up for working on this project)
Since the beginning my intention was to avoid having any secrets within the Dockerfile, so I attempted to get the /ConfigurationFile switch working with the following configuration file:
but to no avail.
Despite following the instructions on the Lansweeper website I never got it working properly.
Interestingly enough since the Lansweper installer is based on Inno Setup I was able to send the logs to C:\temp during install with the command
C:\temp\lansweeper\LansweeperSetup.exe /ConfigurationFile="c:\temp\lansweeper\InstallConfig.ini" /LOG="C:\temp\laninstall.log"
Which when opened is showing that some parameters are indeed being extracted from the configuration file, but not all:
2022-08-16 17:31:25.826 Loading commandline parameters...
2022-08-16 17:31:25.841 Configuration file = c:\temp\lansweeper\InstallConfig.ini
2022-08-16 17:31:25.841 General parameters:
2022-08-16 17:31:25.841 ACCEPTEULA
2022-08-16 17:31:25.841 INSTALL
2022-08-16 17:31:25.841 Database parameters:
2022-08-16 17:31:25.841 Webserver parameters:
2022-08-16 17:31:25.841 HTTPPORT = 81
Quite confusing. I’ve tested it with both uppercase and lowercase parameters with no success.
Anyway, once it became clear that the configuration file idea wasn’t going to pan out I decided to go with a standard “secrets in the Dockerfile” approach for the moment as it was in testing and the priority was to have a functioning Docker Container first, and then implement proper Secrets handling during the build and deployment to Azure.
So after a lot of trial and error and many surprises (like, for example that you have to specify both the password of the lansweeperuser account AND the username/password of the SQL Admin account, or that the paths passed to the /credkeyfile parameter have to be absolute rather than relative to the WORKDIR set in the Dockerfile) I ended up with this:
# Indicates that the windowsservercore image will be used as the base image.
FROM mcr.microsoft.com/windows/servercore:ltsc2022
# Create temp folder
RUN powershell -command New-Item -Path "c:\temp" -Name "lansweeper" -ItemType "directory"
WORKDIR /temp/lansweeper
# Uses dism.exe to install the IIS role.
RUN powershell -command Install-WindowsFeature -name Web-Server -IncludeManagementTools
# Download Lansweeper Installer
ADD LansweeperSetup.exe /temp/lansweeper/LansweeperSetup.exe
# Add InstallConfig.ini
ADD InstallConfig.ini /temp/lansweeper/InstallConfig.ini
# Add Encryption.txt
ADD Encryption.txt /temp/lansweeper/Encryption.txt
# Runs Installer
RUN C:\temp\lansweeper\LansweeperSetup.exe /accepteula /install /parts=web /dbserver="SQLServer" /dbinstance="SQLSERVER\MSSQLSERVER2019" /dbuserconfig="" /credkeyfile="C:\Temp\lansweeper\Encryption.txt" /webserver="iis" /dbuser="SQLAdmin" /dbpassword="" /silent /httpport="81"
# Sets a command or process that will run each time a container is run from the new image.
CMD [ "ping", "localhost", "-t" ]
Which built and deployed properly, including authentication with pre-existing accounts (which means the Encryption.txt file was correctly integrated).
From there on the next step was deploying the infra in Azure and start building the Bicep template for deploying the Container and that’s where I hit the road block that stopped this entire project for the foreseeable future:
So yeah, since the feature has been asked in 2020 no progress has been made with the integration of Windows Containers within a VNET: https://docs.microsoft.com/en-us/answers/questions/189525/windows-container-in-azure-and-network.html
Which means that now I have 2 possibilities:
- Wait until Azure adds support for VNET integration for Windows containers
- Set up a full AKS cluster and try running the containers on that
As my knowledge of Kubernettes is quite limited the second option would require a massive amount of work so it won’t happen in the near future, but if VNET integration is still not available for Azure Container Instances in a few months it could be a very interesting project for learning how to setup an AKS cluster.
Regardless, this is it for the project update!
Additional links on the subject:
https://docs.microsoft.com/en-us/azure/container-instances/container-instances-vnet
https://docs.docker.com/engine/reference/builder/
https://vsupalov.com/docker-arg-env-variable-guide/
https://vsupalov.com/better-docker-build-secrets/
https://blog.sixeyed.com/shh-secrets-are-coming-to-windows-in-docker-17-06/
