Building Complex Software Inside Containers
1
Building Complex Software Inside Containers Calvin Seamons Los Alamos National Laboratory [email protected] LA-UR-19-30257 High performance computing (HPC) applications require a complex network of dependences to operate. HPC centers typically offer these dependencies through the use of module files, that when loaded modify a user’s environment to support their application (gcc, openmpi, etc.). If an HPC system doesn’t support a dependency, codes teams can either find a substitute or request it be added through a system administrator. With the growth and complex nature of HPC applications it is unrealistic for HPC centers to support every unique dependency. We offer containers to support user defined software stacks (UDSS) as an alternative method to the module filesystem. By building Model for Prediction Across Scale (MPAS) inside a container we demonstrate the following: Introduction • Complex Software (with all dependencies) can be built and executed entirely from source, within a container • Nearly identical test results between containers • Software can be built on a production cluster without the use of sudo • If application can be containerized, code teams can use deprecated or bleeding edge software • Applications within container suffer no performance loss and outperform bare metal systems for all MPAS simulations MPAS Simulation Results [Container vs. Bare Metal] MPAS Dependency Trees Trinitite Container [42:41] Grizzly Container [45:44] Container Challenges Executing and Building Containers Conclusion Acknowledgements Mentors: Jordan Ogas, Jennifer Green Thanks to: Dan Magee and Hunter Easterday MPAS is the atmospheric simulation software successfully containerized. Due to its large amount of dependencies, maintaining this software on a cluster is challenging Post Build Modifications Specific systems (e.g. Cray) require modifications to the container after construction. Known as “library injects” this can complicate the container build process hindering their portability and reusability Proprietary Software Containers have trouble interfacing with licensing managers. As a result many compilers and libraries are unsupported, such as: Intel and Allinea compilers, and Kuda libraries. MPAS Dockerfile • Visually identical results on both bare metal and container systems • The Debian9 MPAS containers produced nearly identical output results on systems with different OS and hardware (4bytes changed out of 506MB output.nc files) Dockerfiles, the Recipe for a Container FROM is usually how dockerfiles start. It pulls a base image that serve as the backbone of the container. In this case, the latest version of centos available on Dockerhub. RUN is what you use to execute as command (typically bash). As seen above this is used to ”yum update” as well as. configure and make. ENV sets variables inside a container that are needed upon execution of the container. If you want to save something to your path this is where it happens. WORKDIR is used to specify the location within the filesystem you pulled and stay in that location until otherwise told. A “cd” will only be valid on the line it is called a revert back to “/” when finished. Dockerfiles are the industry standard when it comes to creating containers. They are fairly easy to write and are essentially bash scripts with a few Docker directives to denote what action should take place. Running a Container with Charliecloud Using Charliecloud it’s incredibly easy to run an application inside a container. Once you are on a production cluster it can be achieved in 4 steps. 1. Allocate compute nodes for your application 2. Build or load in Charliecloud 3. Using Charliecloud, unpack the container image (ch-tar2dir) 4. Using Charlieclouds, execute the container runtime (ch-run) The example below shows charliecloud running the MPAS containers supercell simulation $ salloc –N4 --qos=high --time=3:00:00 $ module load charliecloud/0.10 $ ch-tar2dir mpas-debian9.tar.gz /var/tmp $ ch-run -w --unset-env=‘*’ \ --cd=/usr/local/src/supercell/ \ --set-env=/var/tmp/mpas-debian9/ \ ch/environment/var/tmp/mpas-debian9/ \ -- mpirun\ -np 32 ./atmosphere_model MPAS NCL Parallel IO parmetis netcdf-fortran metis netcdf autoconf hdf5 Pnetcdf automake autoconf LFT libiconv zlib automake x2 libxml2 gcc8.2.0 m4 openmpi cmake openssl perl pkgconf ncurses readline gdbm python bzip2 sqlite hl hwloc libpciaccess numactl libtool libtool util-macros Libcurl4 dev libsigsegv Main Dependency Tools Compiler Libraries Core Product Containers prove to be an effective tool when dealing with complicated software. Outperforming bare metal systems while maintaining output accuracy, containers may offer code teams a fantastic alternative to the module filesystem. If an application can be containerized it offers flexibility, access to cutting edge software not available on HPC clusters, and a prescribed build of the application for reusability. Hardware/Software Specifications Hardware Hardware Intel Xeon Broadwell Intel OmniPath CTS-1 X86_64 Cray XC40 Haswell 3D Aries Dragonfly Intel Haswell Software Software Architecture Architecture Interconnect Interconnect CPU: CPU: Grizzly Cluster Trinitite Cluster Container: a container is a process or group of processes within a namespace. An easy way to think about it is filesystem inside another filesystem. Within that namespace is everything you need to execute your application. When running inside a container it also thinks it’s the sole filesystem on the hardware. Tri-Lab Operating System Stack (TOSS3) Debian9 MPAS Simulation Suite Namespace Debian9 MPAS Simulation Suite Namespace Cray Linux Environment SLES- based (CLE6.0) Trinitite Container [11:29] -Lp/lib Trinitite Bare Metal [13:21] -px/lib Grizzly Bare Metal [47:16] Trinitite Container [43:41] • Trinitite container ran 2.34% faster than Trinitite bare metal for supercell simulation • Grizzly container ran 3.31% faster than Grizzly bare metal for supercell simulation • Trinitite container ran 16.25% faster than Trinitite bare metal for mountain wave simulation
Transcript of Building Complex Software Inside Containers
Building Complex Software Inside ContainersCalvin Seamons
Los Alamos National [email protected]
LA-UR-19-30257
High performance computing (HPC) applications require a complex network of dependences tooperate. HPC centers typically offer these dependencies through the use of module files, that whenloaded modify a user’s environment to support their application (gcc, openmpi, etc.). If an HPC systemdoesn’t support a dependency, codes teams can either find a substitute or request it be added througha system administrator. With the growth and complex nature of HPC applications it is unrealistic forHPC centers to support every unique dependency. We offer containers to support user definedsoftware stacks (UDSS) as an alternative method to the module filesystem. By building Model forPrediction Across Scale (MPAS) inside a container we demonstrate the following:
Introduction
• Complex Software (with all dependencies) can be built and executed entirely from source, within a container
• Nearly identical test results between containers
• Software can be built on a production cluster without the use of sudo
• If application can be containerized, code teams can use deprecated or bleeding edge software
• Applications within container suffer no performance loss and outperform bare metal systems for all MPAS simulations
MPAS Simulation Results [Container vs. Bare Metal]
MPAS Dependency Trees
Trinitite Container [42:41]
Grizzly Container [45:44]
Trinitite Bare Metal [43:41]
Container Challenges
Executing and Building Containers
Conclusion
AcknowledgementsMentors: Jordan Ogas, Jennifer GreenThanks to: Dan Magee and Hunter Easterday
MPAS is the atmospheric simulation software successfully containerized. Due to its large amount of dependencies, maintaining this software on a cluster is challenging
Post Build ModificationsSpecific systems (e.g. Cray) requiremodifications to the container afterconstruction. Known as “library injects”this can complicate the container buildprocess hindering their portability andreusability
Proprietary SoftwareContainers have trouble interfacingwith licensing managers. As a resultmany compilers and libraries areunsupported, such as: Intel and Allineacompilers, and Kuda libraries.
MPAS Dockerfile
• Trinitite container ran 2.34% faster than Trinitite bare metal for supercell simulation
• Grizzly container ran 3.31% faster than Grizzly bare metal for supercell simulation
• Trinitite container ran 16.25% faster than Trinitite bare metal for mountain wave simulation
• Visually identical results on both bare metal and container systems
• The Debian9 MPAS containers produced nearly identical output results on systems with different OS and hardware (4bytes changed out of 506MB output.nc files)
Dockerfiles, the Recipe for a Container
FROM is usually how dockerfiles start. It pulls a base image that serve as the backbone of the container. In this case, the latest version of centos available on Dockerhub.
RUN is what you use to execute as command (typically bash). As seen above this is used to ”yum update” as well as. configure and make.
ENV sets variables inside a container that are needed upon execution of the container. If you want to save something to your path this is where it happens.
WORKDIR is used to specify the location within the filesystem you pulled and stay in that location until otherwise told. A “cd” will only be valid on the line it is called a revert back to “/” when finished.
Dockerfiles are the industry standard when it comes to creating containers. They are fairly easy to write and are essentially bash scripts with a few Docker directives to denote what action should take place.
Running a Container with CharliecloudUsing Charliecloud it’s incredibly easy to run an application inside a container. Once you are on a production cluster it can be achieved in 4 steps.
1. Allocate compute nodes for your application
2. Build or load in Charliecloud
3. Using Charliecloud, unpack the container image (ch-tar2dir)
4. Using Charlieclouds, execute the container runtime (ch-run)
The example below shows charliecloud running the MPAS containers supercell simulation
$ salloc –N4 --qos=high --time=3:00:00
$ module load charliecloud/0.10
$ ch-tar2dir mpas-debian9.tar.gz /var/tmp
$ ch-run -w --unset-env=‘*’ \--cd=/usr/local/src/supercell/ \--set-env=/var/tmp/mpas-debian9/ \
ch/environment/var/tmp/mpas-debian9/ \-- mpirun\ -np 32 ./atmosphere_model
MPAS
NCL
Parallel IO parmetis
netcdf-fortran metis
netcdf
autoconf
hdf5
Pnetcdf automakeautoconf
LFT
libiconv
zlib
automake x2
libxml2
gcc8.2.0
m4
openmpi
cmake
openssl
perl
pkgconf
ncurses
readline
gdbm
python
bzip2sqlite
hl
hwloc
libpciaccess numactl
libtool
libtool util-macros
Libcurl4 dev
libsigsegv
Main Dependency
Tools
Compiler
Libraries
Core Product
Containers prove to be an effective tool when dealing with complicated software. Outperforming bare metal systems while maintaining output accuracy, containers may offer code teams a fantastic alternative to the module filesystem. If an application can be containerized it offers flexibility, access to cutting edge software not available on HPC clusters, and a prescribed build of the application for reusability.
Hardware/Software Specifications
Hardware Hardware
Intel Xeon Broadwell
Intel OmniPath
CTS-1 X86_64
Cray XC40 Haswell
3D Aries Dragonfly
Intel Haswell
Software Software
Architecture Architecture Interconnect Interconnect CPU: CPU:
Grizzly Cluster Trinitite Cluster
Container: a container is a process or group of processes within a namespace. An easy way to think about it is filesystem inside another filesystem. Within that namespace is everything you need to execute your application. When running inside a container it also thinks it’s the sole filesystem on the hardware.
Tri-Lab Operating System Stack
(TOSS3)Debian9
MPAS Simulation Suite
NamespaceDebian9
MPAS Simulation Suite
NamespaceCray Linux Environment SLES-
based (CLE6.0)
Trinitite Container [11:29]-Lp/lib
Trinitite Bare Metal [13:21]-px/lib
Grizzly Bare Metal [47:16]
Trinitite Container [43:41] • Trinitite container ran 2.34% faster than Trinitite bare metal for supercell simulation
• Grizzly container ran 3.31% faster than Grizzly bare metal for supercell simulation
• Trinitite container ran 16.25% faster than Trinitite bare metal for mountain wave simulation
![Explaining Successful Docker Images using Pattern Mining ... · chines [10]. Docker permits building, shipping, and running applications inside portable containers. Docker containers](https://static.fdocuments.net/doc/165x107/5f01e1e07e708231d4017f76/explaining-successful-docker-images-using-pattern-mining-chines-10-docker.jpg)
