Docker HowTo

Firefox https://code.medtronic.com/diabetes-software/devops/devops-documentation/-/blob/develop/instructi...
Table of content
Table of content
Purpose
1. Tools
1.1 Docker
1.1.1 Runners
1.2 JFrog Artifactory
1.2.1 Repositories (Storage)
2. Docker image version strategy
2.1 Image naming strategy
Base image
Project image
2.2 Tag Versioning
2.3 Tag strategy example
Conclusion
3. Manage dockerfiles and images
3.1 Resources
3.1.1 GitLab repository for dockerfiles
3.1.2 Storing docker files in the repository
3.1.3 JFrog Artifactory for docker images
3.1.4 JFrog Artifactory for software
4. Use Cases
4.1 Add new base image
4.1.1 Windows
4.2 Create new docker image from existing base image
4.2.1 Windows
4.3 Update existing docker image
4.3.1 Windows
4.4 Update Operating System in the docker image
4.4.1 Windows
4.5 Update docker image with Subcommands (Linux)
4.5.1 Windows
4.5.2 Linux
4.6 Update software version in docker image
4.7 Get container Operating System version
4.7.1 Windows
4.8 Upload software to the Artifactory
Useful links
Purpose
The purpose of this document is to describe the docker strategy and processes related to creating, storing, and versioning docker images.
1. Tools
GitLab CI Components
DevOps CI/CD Cluster Node
1.1 Docker
Docker is a set of platform as a service products that use OS-level virtualization to deliver software in packages called containers. Containers are
isolated from one another and bundle their own software, libraries and configuration files; they can communicate with each other through well-defined
channels.
A Docker image is a file used to execute code in a Docker container. Docker images act as a set of instructions to build a Docker container, like a
template. Docker images also act as the starting point when using Docker. An image is comparable to a snapshot in virtual machine (VM)
environments.
Docker is used to create, run and deploy applications in containers. A Docker image contains application code, libraries, tools, dependencies and other
files needed to make an application run.
1 of 16 2023-04-25, 17:43
1.1.1 Runners
We have two types of operating system that can run docker containers inside Medtronic network as a part of GitLab project CI/CD - Windows and
Linux.
Please find more information here
1.2 JFrog Artifactory

JFrog Artifactory provides a single source of truth for build artifacts and works with JFrog Distribution to efficiently distribute large artifacts across the
enterprise. GitLab package registry supports 8 different package types. JFrog Pipelines is a CI-CD product that works well with its Artifactory repository.
1.2.1 Repositories (Storage)
There are two Artifactory repositories for storing Docker-related data.
The first one diabetes_software-generic-shared-local (Package Type: Generic) - is for storing software that is used for Docker image creation. It is a
public read-only repository. The main idea for this repository is to avoid any external downloads from the internet. All software that is used in CI/CD
should be stored inside the Medtronic infrastructure.
The second repository diabetes_software-docker-shared-local (Package Type: Docker) - is for storing Docker images that are used in projects CI/CD
(repository pipelines).
2. Docker image version strategy
2.1 Image naming strategy
Base image
A base image is the image that is used to create all of your container images. Your base image can be an official Docker image, such as Centos, or you
can modify an official Docker image to suit your needs, or you can create your own base image from scratch.
2 of 16 2023-04-25, 17:43
Example of official (not modified) images:
{organization_URL} / {Artifactory_Top-lvl_group} / {GitLab_Group} / devops / base-images / {OS-type} / {OS-version-short} / {image-

type} : {tag}
organization_URL - URL to Medtronic JFrog Artifactory

Example: case.artifacts.medtronic.com
{Artifactory_Top-lvl_group} - Artifactory top-level group name

Example: diabetes_software-docker-shared-local
{GitLab_Group} - GitLab top-level group name.

Example: Diabetes_Software
{OS-type} - Operating system type ( windows or linux ).
{OS-version-short} - operating system major version.

Example (Windows): 2019
Example (Linux Ubuntu): 20.04
{image-type} - Docker base name type of the image.
Example (Windows): servercore
{tag} - tag version of the base image should contain the exact operating system version.
Example (Windows): 10.0.17763.2300
NOTE: tag name contains the full operating system version, so there is no need to create the intermediate folder with the patch version in the image
name.
Project image
Example with a single main software component:
{organization_URL} / {Artifactory_Top-lvl_group} / {GitLab_Group} / devops / project-images / {OS-type} / {OS-version-short} / {OS-

version-patch} / {component-name} / {component-version} : {tag}



{OS-type} - operating system type

Example: windows
{OS-version-short} - operating system major version (or major and minor version).
{OS-version-patch} - operation system patch version

Example (Linux Ubuntu): 3
{component-name} - main software component in the docker image (software name that is installed in the image. Typically the compiler name)
Example: iar , ms-buildtools
{component-version} - short format of the main image component version

Example: 9.10.2 , 15.0
{tag} - tag version of the docker image in accordance to the Tag Versioning section.
Example: 1.0
Example with two main software components:
{organization_URL} / {Artifactory_Top-lvl_group} / {GitLab_Group} / devops / project-images / {OS-type} / {OS-version-short} / {OS-

version-patch} / {first-component-name} / {first-component-version} / {second-component-name} / {second-component-version} :
{tag}
3 of 16 2023-04-25, 17:43



Example: windows
{OS-version-short} - operating system major version (or major and minor version).

Example (Linux Ubuntu): 3
{first-component-name} - main software component in the docker image (software name that is installed in the image. Typically the compiler name).
{first-component-version} - short format of the main image component version.

Example: 9.10.2 , 15.0
{second-component-name} - a second software component that is used with the first component.
Example: coverity , bullseye
{second-component-version} - short format of the main image component version.

Example: 2021.12.0 , 8.25.7
{tag} - tag version of the docker image in accordance to the Tag Versioning section.
Example: 1.0
2.2 Tag Versioning

Semantic versioning has been chosen as a basis. Each time when the image is updated, the DevOps engineer creates three tags for the same image.
Some tags will be overwritten.
For better understanding please see the Tag strategy example section.
{Major Version}.{Minor Version}
Major Version
The Major software number is denoted by an integer. This number is incremented when the following modifications have been made:
Added a new component to the docker image

One of the components/libraries were updated with a new version
When the Major version is incremented, the Minor version must be reset to 0.
Minor Version
The Minor software number is denoted by an integer. This number is incremented when the following modifications have been made:
Bug Fixes in the script inside the image

Small updates in the image configuration files
Package update or installation !!! TBD !!!
New Docker image

New Docker image should be created each time when:
base image operating system was updated

base image operating system type was changed
main image component (Compiler/Framework/Tool) software version was updated.
All initial Docker images should have the following tags: :1.0 , :1 , latest .
For better understanding please see the Tag strategy example section.
2.3 Tag strategy example
Let's take a look at the versioning on a specific example below.

We have an initial docker image with three tags that are pointing to the same digest.
4 of 16 2023-04-25, 17:43
During development, the team has observed incorrect behavior during compilation. The development team has requested an update.
The DevOps team has found a bug in the script. So they have made a fix and updates to the docker image.
The Minor version has been incremented.
The image name remains the same.
All tags were added to the new image (please see case 2 image below)
We can see that two tags were overwritten with the new image and now they are pointing to the most recent docker image.
There was a request from the development team to update the existing image with a new component.
DevOps team has installed the required components in the docker image and incremented the Major version.
The image was pushed to the Artifactory with three tags.
The image name remains the same.
This time only one tag was overwritten. Let's see the image below.
5 of 16 2023-04-25, 17:43
In the next request, some additional Python packages were installed. Docker image and tags were updated accordingly.
Please see image case 4 below.
The development team asked to expose some ports in the docker image. The Minor version has been incremented.
In the example below, the docker base image (the operating system) was updated with a newer version.
This update will affect the image name, that means that image will have new location in the Artifactory.
Initial project image with tree tags was created accordingly.
6 of 16 2023-04-25, 17:43
Conclusion
We have three ways of pointing to the docker image.
1. <major>.<minor> - this tag will not be overwritten. This tag will always point to the same image even if a newer version exists.
2. <major> - this tag will point to the image that will always contain the latest fixes for the same OS, Software and library/package versions.
3. <latest> - this tag will contain the most recent updates to the image in the scope of the fixed version of compiler/framework/tool.
3. Manage dockerfiles and images
3.1 Resources
3.1.1 GitLab repository for dockerfiles
Repository for storing dockerfiles (dockerfiles folder):
Repository for storing docker images:

https://case.artifacts.medtronic.com/artifactory/webapp/#/artifacts/browse/tree/General/diabetes_software-docker-shared-local
In the repository /dockerfiles/readme.md file stored all information regarding docker images in the following format.
Dockerfile Docker image Tag Base Image
case.artifacts.medtronic.com/diabetes_software-
docker-shared-local/diabetes-software/devops mcr.microsoft.com/windows
No Dockerfile (Base Image) 10.0.17763.2300
/base-images/windows /servercore:10.0.17763.2300
/2019/servercore:10.0.17763.2300
dockerfiles/windows case.artifacts.medtronic.com/diabetes_software- case.artifacts.medtronic.com/diabetes_software-

/2019/10.0.17763.2300/base- docker-shared-local/diabetes-software/devops docker-shared-local/diabetes-software/devops
1:0
image/tools/Dockerfile.python- /base-images/windows/2019/10.0.17763.2300 /base-images/windows
git-1.0 /tools/python-git:1.0 /2019/servercore:10.0.17763.2300
case.artifacts.medtronic.com/diabetes_software- case.artifacts.medtronic.com/diabetes_software-
dockerfiles/windows
docker-shared-local/diabetes-software/devops docker-shared-local/diabetes-software/devops
/2019/10.0.17763.2300/iar/9.10.2 1.0
/project-images/windows /base-images/windows/2019/10.0.17763.2300
/Dockerfile.iar-9.10.2-1.0
/2019/10.0.17763.2300/iar/9.10.2:1.0 /tools/python-git:1.0
dockerfiles/windows case.artifacts.medtronic.com/diabetes_software-
docker-shared-local/diabetes-software/devops
/2019/10.0.17763.2300/iar/9.10.2 docker-shared-local/diabetes-software/devops
/project-images/windows 1.0
/coverity/2021.12.0 /project-images/windows
/2019/10.0.17763.2300/iar/9.10.2/coverity
/Dockerfile.coverity-2021.12.0-1.0 /2019/10.0.17763.2300/iar/9.10.2:1.0
/2021.12.0:1.0
dockerfiles/windows case.artifacts.medtronic.com/diabetes_software- case.artifacts.medtronic.com/diabetes_software-

/2019/10.0.17763.2300/ms- docker-shared-local/diabetes-software/devops docker-shared-local/diabetes-software/devops
1.0
buildtools/16.11 /project-images/windows /base-images/windows/2019/10.0.17763.2300
/Dockerfile.ms_buildtools2019-1.0 /2019/10.0.17763.2300/ms-buildtools/16.11:1.0 /tools/python-git:1.0
7 of 16 2023-04-25, 17:43
Dockerfile Docker image Tag Base Image
dockerfiles/windows case.artifacts.medtronic.com/diabetes_software-
docker-shared-local/diabetes-software/devops
/2019/10.0.17763.2300/ms- docker-shared-local/diabetes-software/devops
/project-images/windows 1.0
buildtools/16.11/bullseye/8.25.7 /project-images/windows
/2019/10.0.17763.2300/ms-buildtools/16.11
/Dockerfile.bullseye-8.25.7-1.0 /2019/10.0.17763.2300/ms-buildtools/16.11:1.0
/bullseye/8.25.7:1.0
Microsoft servercore:
https://hub.docker.com/_/microsoft-windows-servercore
Microsoft .NET Framework SDK:

https://hub.docker.com/_/microsoft-dotnet-framework-sdk/
Microsoft nanoserver:
https://hub.docker.com/_/microsoft-windows-nanoserver
Ubuntu:
https://hub.docker.com/_/ubuntu?tab=tags
3.1.2 Storing docker files in the repository

Repository for storing dockerfiles (dockerfiles folder):
https://code.medtronic.com/diabetes-software/devops/devops-build-scripts.git
For better traceability it is recommended to keep folder structure similar to JFrog Artifactory structure.
. / dockerfiles / {OS-type} / {OS-version-short} / {OS-version-patch} / {component-name} / {component-version} / dockerfile.{software-

info}-{tag-version}
NOTE: Dockerfile location should be very similar to the Artifactory location for better traceability.
. - root of the repository

Example: windows
{OS-version-short} - operation system version (short)

Example (Ubuntu): 20-04

Example with Windows: 10-0-17763-2300
Example with Ubuntu: 3
{component-name} - main software component in the docker image (software name that is installed in the image. Typically the compiler name)
{component-version} - short format of the main image component version

Example: 9.10.2 , 15.0
{software-info} - the custom name that will help the user to identify Dockerfile usage. If this image is "project-specific", then Dockerfile could contain
the repository name.
{tag-version} - version of the dockerfile Example: 1.0
Example of full path to the dockerfile (from the repository root location)
./dockerfiles/windows/2019/10.0.17763.2300/iar/9.10.2/Dockerfile.iar-9.10.2-1.0
3.1.3 JFrog Artifactory for docker images
All Diabetes Software project docker images will be stored under diabetes_software-docker-shared-local location.
Artifactory URL:
https://case.artifacts.medtronic.com/
Artifactory common folder for docker images:

https://case.artifacts.medtronic.com:443/artifactory/diabetes_software-docker-shared-local/diabetes-software/devops
Artifactory common folder for docker base images (Windows and Linux):
https://case.artifacts.medtronic.com:443/artifactory/diabetes_software-docker-shared-local/diabetes-software/devops/base-images/windows/
8 of 16 2023-04-25, 17:43
https://case.artifacts.medtronic.com:443/artifactory/diabetes_software-docker-shared-local/diabetes-software/devops/base-images/linux/
Artifactory common folder for software (installed in containers and VMs):

https://case.artifacts.medtronic.com:443/artifactory/diabetes_software-generic-shared-local/diabetes-software/software
3.1.4 JFrog Artifactory for software
All software that is used in the docker images will be stored under diabetes_software-generic-shared-local location.
Artifactory URL:
https://case.artifacts.medtronic.com/
Common diabetes software folder:

https://case.artifacts.medtronic.com:443/artifactory/diabetes_software-generic-shared-local/diabetes-software/software
Keep the software installer location with the version and name.
{Organization_URL} / artifactory / {Artifactory_Top-lvl_group} / {GitLab_Group} / software / {tool-purpose} / {tool-name} / {tool-

version} / {tool-installer}
Organization_URL - URL to Medtronic JFrog Artifactory

Example: https://case.artifacts.medtronic.com

Example: diabetes_software-generic-shared-local

{tool-purpose} - the main purpose of the software tool

Example: build-tools , static-analysis
{tool-name} - name of the tool.

Example: IAR , Coverity
{tool-version} - tool version number.

Example: 9.10.2 , 2021.12.0
{tool-installer} - installer name or archive name.

Example: cov-analysis-win64-2021.12.0.exe , IAR_9.10.2.tgz , IAR_9.10.2.zip
NOTE: There might be cases when the tool does not have an installer or it does not support installation from the command line in the container. In this
case, it is recommended to create an archive zip or tar for this tool.
Example of full path to the tool in the artifactory:

https://case.artifacts.medtronic.com:443/artifactory/diabetes_software-generic-shared-local/diabetes-software/software/static-analysis/coverity
/2021.12.0/cov-analysis-win64-2021.12.0.exe https://case.artifacts.medtronic.com:443/artifactory/diabetes_software-generic-shared-local/diabetes-
software/software/build-tools/IAR/9.10.2/iar_9.10.2.zip
4. Use Cases
4.1 Add new base image
4.1.1 Windows
The base image - is the officially released Docker image by the distributor. Initial Docker image pulled from official sources and saved in the
Artifactory without any modifications.
Preconditions: Docker software is installed
IMPORTANT: Windows requires the host OS version to match the container OS version. If you want to run a container based on a newer Windows
build, make sure you have an equivalent host build.
1. Clone devops-build-scripts repository.

2. Create new feature branch in the devops-build-scripts repository.
3. Open powershell terminal with administrator privileges.
4. Pull docker image from the official source.
docker pull {[image-name]:[TAG]}
9 of 16 2023-04-25, 17:43
Example:
docker pull mcr.microsoft.com/windows/servercore:10.0.17763.2300
5. Update the TAG for Docker image in accordance to naming strategy described in section 2.1.
docker tag {[SOURCE_IMAGE]:[TAG]} {[TARGET_IMAGE]:[TAG]}
Example:
docker tag mcr.microsoft.com/windows/servercore:10.0.17763.2300 case.artifacts.medtronic.com/diabetes_software-docker-shared-local/diabetes
6. Check if new TAG was added.
docker image ls
7. Log in to the Artifactory.
docker login -u {user_id} {remote_repository_url}
Where:
[user_id] - Medtronic user ID (login)
[remote_repository_url] - JFrog Artifactory URL Example:
docker login -u "halkim1" "case.artifacts.medtronic.com"
8. Push image to the JFrog Artifactory.
docker push {TARGET_IMAGE[:TAG]}
Example:
docker push case.artifacts.medtronic.com/diabetes_software-docker-shared-local/diabetes-software/devops/base-images/windows/2019/servercore
9. Log out from Artifactory.
docker logout {remote_repository_url}
Where:
docker logout "case.artifacts.medtronic.com"
10. Update /dockerfiles/readme.md table in the devops-build-scripts repository with new image information.
11. Add updated registry table to the devops-build-scripts repository.
12. Commit changes.
13. Create a merge request and assign a reviewer.
14. After the merge request has been reviewed branch should be merged.
4.2 Create new docker image from existing base image
4.2.1 Windows
Preconditions: Docker software is installed
Before starting image creation you should have compleate list of required tools and dependencies.
All software should be uploaded to the Artifactory repository diabetes_software-generic-shared-local . check section 3.1.4

10 of 16 2023-04-25, 17:43
3. Create Dockerfile in appropriate location with well informative naming (TAG - section 2.2, Dockerfile naming - section 3.1.2).
4. Define Base image in Dockerfile .
FROM {[image-name]:[TAG]}
Example:
FROM case.artifacts.medtronic.com/diabetes_software-docker-shared-local/diabetes-software/devops/base-images/windows/2019/servercore:10.0.1
5. Add instructional steps to Dockerfile and save changes.

NOTE: This example contains steps with Python and Git client installation. All required software was uploaded to the Artifactory before image
creation (section3.1.4). RUN steps contain three operations: Download, Install, and installation file removal. This was done for image size
optimization.
Example:
# Download and install Python 3.8.6

RUN powershell.exe -Command \
Invoke-WebRequest https://case.artifacts.medtronic.com:443/artifactory/diabetes_software-generic-shared-local/diabetes-software/softwar
Start-Process c:\python-3.8.6.exe -ArgumentList '/quiet InstallAllUsers=1 PrependPath=1' -Wait ; \
Remove-Item c:\python-3.8.6.exe -Force
# Download and install pip
Start-Process python c:\get-pip.py -Wait ; \
Remove-Item c:\get-pip.py -Force
# Download and install git
Start-Process c:\Git-2.32.0.2-64-bit.exe -ArgumentList '/VERYSILENT /NORESTART' -Wait ; \
Remove-Item c:\Git-2.32.0.2-64-bit.exe -Force
6. Open powershell terminal with administrator privileges and navigate to the directory with the newly created dockerfile .
7. Build docker image from Dockerfile with tag version format {major}.{minor} .
docker build -t {[image-name]:[{major}.{minor}]} -f {[Dockerfile-name]} .
Example:
docker build -t case.artifacts.medtronic.com/diabetes_software-docker-shared-local/diabetes-software/devops/project-images/windows/2019/10.
8. Check if new image was built.
docker image ls
9. Create rest of the tags.
docker tag {[image-name]:[{major}.{minor}]} {[image-name]:[{major}]}

docker tag {[image-name]:[{major}.{minor}]} {[image-name]:latest}
Example:
docker tag case.artifacts.medtronic.com/diabetes_software-docker-shared-local/diabetes-software/devops/project-images/windows/2019/10.0.177

10. Check if all tags were created.
docker image ls
11 of 16 2023-04-25, 17:43
Where:
12. Push image with all tags to the JFrog Artifactory.
docker push {[image-name]:[TAG]}
Example:
docker push case.artifacts.medtronic.com/diabetes_software-docker-shared-local/diabetes-software/devops/project-images/windows/2019/10.0.17

Where:
14. Update registry table /dockerfiles/readme.md with new image information.
15. Add updated registry table and new dockerfile to the devops-build-scripts repository.
16. Commit changes.
4.3 Update existing docker image
4.3.1 Windows

NOTE: If change does not affect the main components of the docker image, create a new dockerfile on the same level as the previous one and
then update the tag version accordingly.
4. Define the Base image in Dockerfile (use the most recent one, where the change should be added).
FROM {[image-name]:[TAG]}
Example:
FROM case.artifacts.medtronic.com/diabetes_software-docker-shared-local/diabetes-software/devops/project-images/windows/2019/10.0.17763.230
5. Update Dockerfile with required commands and save the file.
7. Build docker image from Dockerfile with a new tag version {major}.{minor} .
docker build -t {[image-name]:[{major}.{minor}]} -f {[Dockerfile-name]} .
Example:
12 of 16 2023-04-25, 17:43
docker build -t case.artifacts.medtronic.com/diabetes_software-docker-shared-local/diabetes-software/devops/project-images/windows/2019/10.
8. Check if image was created.
docker tag {[image-name]:[{major}.{minor}]} {[image-name]:[{major}]}

docker tag {[image-name]:[{major}.{minor}]} {[image-name]:latest}
Example:

docker image ls
Where:
12. Push image with all tags to the JFrog Artifactory.
Example:

Where:
16. Commit changes.
4.4 Update Operating System in the docker image
4.4.1 Windows
Preconditions: Base image should be prepeared (pushed to Artifactory) Section 4.1

13 of 16 2023-04-25, 17:43
4. If you need to upgrade the operating system for a Docker image that has multiple versions, then you need to combine all the Dockerfiles into the
new one (deleting repetitive instructional steps but keeping the correct order).
5. In the line where base image is defined FROM , replace old base image URL with new base image URL.
6. Save changes and close the file.
8. Build docker image from Dockerfile with a new tag version {major}.{minor} .
NOTE: Since you are updating the Operating System version, and this is affecting the Dockerfile and Artifactory image location, the Dockerfile tag
most likely will start with version 1.0.
docker build -t {[image-name]:[TAG]} .
9. Check if new image was built.
docker image ls
docker tag {[image-name]:[{major}.{minor}.{patch}]} {[image-name]:[{major}.{minor}]}

docker tag {[image-name]:[{major}.{minor}.{patch}]} {[image-name]:[{major}]}
docker tag {[image-name]:[{major}.{minor}.{patch}]} {[image-name]:latest}
docker image ls
13. Push image to the JFrog Artifactory
17. Commit changes.
4.5 Update docker image with Subcommands (Linux)
4.5.1 Windows
TODO
4.5.2 Linux
TODO
4.6 Update software version in docker image

TODO
14 of 16 2023-04-25, 17:43
4.7 Get container Operating System version
4.7.1 Windows
Where:
3. pull needed docker image from Artifactory.
docker pull {image name and tag}
Example:
docker pull case.artifacts.medtronic.com/diabetes_software-docker-shared-local/diabetes-software/devops/base-images/windows/2019/servercore
4. Run container locally.
docker run -it {image name and tag}
Example:
docker run -it case.artifacts.medtronic.com/diabetes_software-docker-shared-local/diabetes-software/devops/base-images/windows/2019/serverc
5. Verify that container is running.
6. Execute PowerShell command.
Get-ItemProperty -Path "HKLM:\Software\Microsoft\Windows NT\CurrentVersion" | Select ProductName, ReleaseId, InstallationType
7. Exit from container.
4.8 Upload software to the Artifactory

Preconditions: Before uploading software to the Artifactory please get familiar with section 3.1.4.
All software files/archives should be prepeared locally before starting this guide.
1. Open Medtronic Artifactory page in the web browser.

2. Click on the Login button in the upper right corner.
3. Enter Medtronic user credentials in the pop-up window and click Login button.
4. On the left side panel select Artifacts option.
5. Find needed Artifactory Top-level repository in the Artifact Repository Browser and click on it.
6. Expand repository structure and select needed location.
NOTE: If needed location does not exist, skip this step.
7. At the right side of the window click on the Deploy button.
8. Select required Target Repository from drop down window.
9. Click on the Select file option and choose needed file.
10. Check the Target Path field. If the proposed location does not satisfy requirements from section 3.1.4, update Target Path manually.
11. Click on the Deploy button to upload software to the Artifactory.
Useful links
15 of 16 2023-04-25, 17:43
best practices https://docs.docker.com/develop/develop-images/dockerfile_best-practices/
16 of 16 2023-04-25, 17:43

Docker HowTo

Uploaded by

Copyright:

Available Formats

Docker HowTo

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Docker HowTo

Uploaded by

Copyright:

Available Formats

Firefox https://code.medtronic.com/diabetes-software/devops/devops-documentation/-/blob/develop/instructi...

DevOps CI/CD Cluster Node

Please find more information here

1.2 JFrog Artifactory

1.2.1 Repositories (Storage)

There are two Artifactory repositories for storing Docker-related data.

2. Docker image version strategy

2.1 Image naming strategy

Example of official (not modified) images:

{organization_URL} / {Artifactory_Top-lvl_group} / {GitLab_Group} / devops / base-images / {OS-type} / {OS-version-short} / {image-

organization_URL - URL to Medtronic JFrog Artifactory

{Artifactory_Top-lvl_group} - Artifactory top-level group name

{GitLab_Group} - GitLab top-level group name.

{OS-type} - Operating system type ( windows or linux ).

{OS-version-short} - operating system major version.

{image-type} - Docker base name type of the image.

Example (Windows): servercore

Example with a single main software component:

{organization_URL} / {Artifactory_Top-lvl_group} / {GitLab_Group} / devops / project-images / {OS-type} / {OS-version-short} / {OS-

organization_URL - URL to Medtronic JFrog Artifactory

{Artifactory_Top-lvl_group} - Artifactory top-level group name

{GitLab_Group} - GitLab top-level group name.

{OS-type} - operating system type

{OS-version-patch} - operation system patch version

{component-version} - short format of the main image component version

Example with two main software components:

{organization_URL} / {Artifactory_Top-lvl_group} / {GitLab_Group} / devops / project-images / {OS-type} / {OS-version-short} / {OS-

organization_URL - URL to Medtronic JFrog Artifactory

{Artifactory_Top-lvl_group} - Artifactory top-level group name

{GitLab_Group} - GitLab top-level group name.

{OS-type} - operating system type

{OS-version-patch} - operation system patch version

{first-component-version} - short format of the main image component version.

{second-component-version} - short format of the main image component version.

2.2 Tag Versioning

{Major Version}.{Minor Version}

Added a new component to the docker image

Bug Fixes in the script inside the image

New Docker image

base image operating system was updated

2.3 Tag strategy example

Let's take a look at the versioning on a specific example below.

We have three ways of pointing to the docker image.

3. Manage dockerfiles and images

3.1.1 GitLab repository for dockerfiles

Repository for storing dockerfiles (dockerfiles folder):

Repository for storing docker images:

Dockerfile Docker image Tag Base Image

dockerfiles/windows case.artifacts.medtronic.com/diabetes_software- case.artifacts.medtronic.com/diabetes_software-

dockerfiles/windows case.artifacts.medtronic.com/diabetes_software- case.artifacts.medtronic.com/diabetes_software-

Dockerfile Docker image Tag Base Image

Microsoft .NET Framework SDK:

3.1.2 Storing docker files in the repository

. / dockerfiles / {OS-type} / {OS-version-short} / {OS-version-patch} / {component-name} / {component-version} / dockerfile.{software-

. - root of the repository

{OS-type} - operating system type

{OS-version-short} - operation system version (short)

{OS-version-patch} - operation system patch version

{component-version} - short format of the main image component version