IncrediBuild is a distributed computing solution that recruits other machines’ CPU power in order to parallelize tasks and thereby to reduce development cycles by up to 90%.
Basically, since version 9.3, an IncrediBuild Agent can be installed and run on docker containers, as an Initiator and as a Helper. The idea of using containerised Agents is to allow a fast and lightweight Agent to participate in builds on demand and to shut it down when not in use, in a single command line.
In order to run an IncrediBuild image, one needs to fulfil the followings:
Install Docker Desktop. Pay attention to Docker's installation prerequisites.
Once Docker Desktop installation is complete, right-click on the Docker icon (a good looking grey whale) in the taskbar → Switch to Windows containers. There are two states the Docker service can run, and we need the "Windows containers" one.
There are 3 main flows of how to add your containerised Agent to the grid:
A. As a Helper - pull the image from Docker-Hub, and run it as is. For example:
docker pull incredibuild/9.5.0
docker run [OPTIONS] incredibuild/9.5.0 [COMMAND] [ARG...] → (see more details in the "docker run" section).
B. As an Initiator - build your own image, based on IncrediBuild's image, and import into it your build tools. For example:
i. Create a Dockerfile with the following content:
FROM incredibuild/9.5.0 # (basic image)
RUN mkdir C:\\BuildTools
WORKDIR C:\\BuildTools
COPY C:\\Host\\BuildToolsDirectory . # (import build tools and necessary binaries)
and so on...
ii. Build the image using docker build command.
iii. Instantiate a container from the built image using the docker run command - see details in the "docker run" section.
C. Use your already existing Dockerfile (with your organization settings, for example), and add to it the steps of installing IncrediBuild's Agent using the console installer. The console installer can be easily generated using IncrediBuild's GUI installer. This option allows the freedom of choice inside the image, such as in OS, build tools, IncrediBuild (supported) version, installation directory, etc. For example:
FROM mcr.microsoft.com/windows/servercore:ltsc2016
RUN mkdir C:\\Installers
COPY C:\\Path\\To\IncrediBuild\Version_9_5_0_ConsoleInstaller.exe C:\\Installers\\IB_ConsoleInstaller.exe
RUN C:\\Installers\\IB_ConsoleInstaller.exe / # Run IncrediBuild console installer.
&& /install / # Install. Other options are /repair, /update, /uninstall.
&& /installdir="C:\IncrediBuild\InstallDir" / # Set installation directory.
&& /components=agent / # Install Agent component only. In case of using the 'suvm' tag, use "/components=agent,oneuse".
&& /coordinator=192.168.10.10:31104 / # Connect to the Coordinator in IP address 192.168.10.10, that is listening on port 31104.
&& /agent:serviceport=31105 / # Set BuildService port.
&& /agent:helperport=31106 # Set BuildHelper(s) port(s), according to the allocated CPUs for the container, which is automatically detected by the installer.
RUN mkdir C:\\BuildTools
WORKDIR C:\\BuildTools
COPY C:\Path\To\Host\BuildToolsDirectory . # (import build tools and necessary binaries)
and so on...
NOTE: Containerised Agents cannot run on Microsoft Nano Server OS, since this OS can run only 64-bit based applications, and a part of IncrediBuild's applications are 32-bit based.
docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...]
This is the basic command used to create a container from an image. The image can be reused and cached on the host machine if it was already pulled, or can be pulled on-the-fly while trying to run it for the first time.
In order for the containerised Agent to be valid, subscribed to its Coordinator, participate in builds, etc., one should configure the following basic properties, using the docker run command (full example and detailed explanation below):
Mandatory command line arguments for flows A + B:
-e Coordinator="coordinator_hostname_or_ip_address" → Set the Coordinator to connect to, using the "Coordinator" environment variable.
-e CoordinatorPort="coordinator_port" → Set the port the Coordinator is listening to, using the "CoordinatorPort" environment variable.
-e BuildServicePort="buildservice_port" → Set BuildService port, using the "BuildServicePort" environment variable.
-e BuildHelperPort="buildhelper_port" → Set BuildHelper(s) port(s), using the "BuildHelperPort" environment variable. The given value sets the lowest port number to require from the host's OS, and will result in owning the sequential port numbers according to the allocated cores. For example - in case the container has 4 cores, and the BuildHelperPort is set to 33000, the Agent will eventually use the 4 following ports - 33000, 33001, 33002 and 33003.
-p host_port:container_port/tcp → Publish container's container_port and bind to host's host_port, to have access from the containerised Agent to the Coordinator and the other Agents, and vice-versa.
NOTE: Both BuildServicePort and BuildHelperPort(s) will have to be exposed during the container's creation, in order for the containerised Agent to communicate with other Agents and the Coordinator. For more information on ports exposure, refer to "-p=[]" command line argument in docker run.
Full example:
This command below creates and runs the following container (ordered):
docker run --cpus 8 -e Coordinator="192.168.10.10" -e CoordinatorPort="22222" -e BuildServicePort="33333"
-e BuildHelperPort="44444" --rm -it -p 33333:33333/tcp -p 44444-44451:44444-44451/tcp incredibuild/9.5.0:latest
BuildConsole.exe /command="MyDockerSample.bat" /avoidlocal=on /title="Docker Sample"
docker run → run a container based on these parameters:
--cpus 8 → allocates 8 cores from the host machine.
-e Coordinator="192.168.10.10" → connects the Agent to the Coordinator in IP Address 192.168.10.10.
-e CoordinatorPort="22222" → sets the port the Coordinator listens to to 22222.
-e BuildServicePort="33333" → sets BuildService port to 33333.
-e BuildHelperPort="44444" → sets BuildHepler(s) ports starting from 44444, so in this case the container will use ports range 44444-44451.
--rm → removes container when it exits.
-it → sets interactive STDIN mode and connects to the container's pseudo-tty.
-p 33333:33333/tcp → publish and bind port 33333 of the container to its mapped host port for the Agent BuildService.
-p 44444-44451:44444-44451/tcp → publish and bind port range 44444-44451 to their mapped host ports. The range consists of 8 ports due to 8 cores the Agent can utilize as Helper from the host running on.
incredibuild/9.5.0:latest → from IncrediBuild's repository, use the 9.5.0 version latest image.
BuildConsole.exe /command="MyDockerSample.bat" /avoidlocal=on /title="Docker Sample" → execute a build, using BuildConsole.exe with its given arguments.
NOTE: Once the container is removed, the license allocation remains as if the Agent is temporarily offline, and is supposed to reconnect to the grid in the future. This means that the license packages for the containerised Agent will need to be manually deallocated from the Coordinator Monitor, in order to allocate them to another subscribed Agent. In order to easily manage allocated license packages for removed containers, consider using the Single-Use VM feature, which is available in the 'suvm' tagged image (explanation below).
SUVM which stands for Single-Use VM, is a feature that allows automatic license packages deallocation once the container is stopped or removed. This comes in handy for automatic build environments that provision virtual machines on demand, and need to free their resources from the no-longer existing containers. This feature is available only for the IncrediBuild Enterprise edition. For more information about the Signle-Use VM visit IncrediBuild's confluence.
OS - Windows Server Core 2019 - latest version.
IncrediBuild version-specific console installer located under C:\IB\IBConsoleSetup.exe. The Agent is already installed, and it is using the default installation directory - C:\Program Files (x86)\IncrediBuild. The installation directory is added to the PATH environment variable.
The docker default OS settings:
a. CPU sharing - 2 cores (default).
b. Memory - Infinite (default).
c. Network - NAT (default).
d. Ports - not exposed. See note above regarding the necessity of ports exposure during execution of "docker run" or inside the user-defined Dockerfile.
Content type
Image
Digest
Size
2.3 GB
Last updated
almost 6 years ago
docker pull incredibuild/9.5.0:suvm