Windows-konttien soveltuvuus laajan ohjelmiston koontiympäristöksi
Eikkula, Toni (2024)
2024
Tietotekniikan DI-ohjelma - Master's Programme in Information Technology
Informaatioteknologian ja viestinnän tiedekunta - Faculty of Information Technology and Communication Sciences
This publication is copyrighted. You may download, display and print it for Your own personal use. Commercial use is prohibited.
Hyväksymispäivämäärä
2024-12-19
Julkaisun pysyvä osoite on
https://urn.fi/URN:NBN:fi:tuni-2024121611220
https://urn.fi/URN:NBN:fi:tuni-2024121611220
Tiivistelmä
Perinteinen palvelinten hallinta on työlästä. Ohjelmisto on pidettävä päivitettynä ja laitteiston kuntoa seurattava. M-Filesin koontipalvelinten ylläpitoon kului työtunteja. Ylläpitoon liittyi runsaasti manuaalista työtä. Koontipalvelimilla ajettiin erityyppisiä ohjelmistokehitykseen liittyviä automaatiotehtäviä, kuten yksikkötestejä. M-Filesin ydinohjelmiston koonti lähdekoodista asennustiedostoiksi oli keskeisin palvelinten suorittama tehtävä. Koonti tehtiin Setup Builderilla, joka oli M-Filesin itse kehittämä koonninohjaustyökalu.
Kontitus nähtiin yhtenä ratkaisuna, jolla palvelinten ylläpitotaakka olisi vähennettävissä. Kaikki koontipalvelimilla ajetut tehtävät haluttiin kontittaa. Tulevaisuuden tavoite oli, että kontitetut tehtävät ajettaisiin pilvessä, jolloin paikallisista palvelimista voitaisiin luopua. Konttiin käärityt tehtävät olisi helpompi siirtää pilviympäristöön.
Kontitus on suosittu ja kevyt virtualisointiteknologia. Kontituksessa on kyse siitä, että ohjelmisto ja kaikki sen riippuvuudet paketoidaan konttikuvaan. Kontti on kertakäyttöinen ajoympäristö, joka luodaan konttikuvasta ja jossa ohjelmisto toimii aina samalla tavalla. Konttikuvat rakennetaan tekstipohjaisen määrittelytiedoston pohjalta, joka on ihmisen luettavassa muodossa. Ohjelmiston ajoympäristö on hallittavissa helposti ja tehokkaasti konttikuvana ja sen määrittelytiedostona.
Tässä diplomityössä selvitettiin, soveltuvatko Windows-kontit Setup Builderin ajoympäristöksi. Kaikkien käytettyjen kehitys- ja koontityökalujen oli asennuttava konttiin ja toimittava normaalisti. Setup Builderin tuli olla ajettavissa kontissa loppuun asti. Myös suorituskykyvaikutusten selvitys nähtiin tärkeänä. Setup Builderin suoritusaika ja resurssienkäyttö eivät saaneet kasvaa liikaa kontissa.
Diplomityössä toteutettiin onnistuneesti konttikuva, josta luodussa kontissa Setup Builder oli ajettavissa normaalisti, toistettavasti ja vakaasti. Konttikuvan toteutuksen alkupuolella kohdattiin kuitenkin useita ongelmia. Toteutukseen kului moninkertaisesti odotettua enemmän aikaa. Windows-pohjaisten sovellusten kontituksessa on varauduttava ongelmanratkontaan. Ongelmien esiintymiseen vaikuttaa oleellisesti se, mitä työkaluja konttiin on asennettava.
Lopussa kontitetulle Setup Builderille tehtiin suorituskykymittaukset. Mittauksiin liittyi useita mittaustapauksia. Windows-kontteja voi ajaa kahdella vaihtoehtoisella eristystasolla, prosessieristyksessä ja Hyper-V-eristyksessä, jota kutsuttiin teknologianeutraalimmin virtuaalikone-eristykseksi. Jälkimmäinen eristystaso on hybridiratkaisu, jossa konttia ajetaan pitkälle optimoidussa ja kevyessä utiliteettivirtuaalikoneessa. M-Filesillä oli oma, paikallinen laskentaverkko, joka nopeutti komponenttien kääntämistä. Mittaukset suoritettiin erikseen tapauksille, joissa laskentaverkko avustaa koontia, ja tapauksille, jossa laskentaverkkoa ei käytetä.
Tulosten perusteella prosessieristetyt Windows-kontit soveltuvat erinomaisesti M-Filesin kaltaisen laajan ohjelmiston koontialustaksi. Setup Builderin suoritusaika kasvoi vähemmän kuin 10 % riippumatta siitä, käytettiinkö laskentaverkkoa. Muistinkulutus ja suorittimenkäyttö eivät muuttuneet oleellisesti prosessieristetyssä kontissa.
Virtuaalikone-eristetyt Windows-kontit eivät menestyneet mittauksissa. Setup Builderin suoritusaika ja muistinkulutus lisääntyivät valtavasti. Alussa oletettiin, että laskentaverkon käyttö vähentäisi virtuaalikone-eristyksen vaikutusta koonnin suorituskykyyn, koska osa raskaasta käännöstyöstä on delegoitu laskentaverkolle. Oletuksen vastaisesti suorituskykyvaikutukset korostuivat laskentaverkkoa käytettäessä. Virtuaalikone-eristyksen negatiiviset suorituskykyvaikutukset saattavat olla kuitenkin vähennettävissä tunnistamalla ja poistamalla pullonkaulat. Typically, it is a laborious task to maintain traditional servers. Administrators must keep the software updated and follow the condition and health of the hardware. The maintenance of local build servers at M-Files consumed working hours, that involved a great deal of manual work. The servers provided runtime environment for a variety of software development related automation tasks like unit tests. Building the main product of M-Files was the most important task hosted on the servers. The process was done by Setup Builder, an in-house developed build automation software, that generated deliverable installers from the source code.
Containerization was seen as a solution to the maintenance burden. We wanted to containerize each task hosted on the build servers. The future plan was to retire the local servers and run the tasks on a cloud environment. The transition would be easier with containerized tasks.
Containerization is a widespread and lightweight virtualization technology. When an application is containerized, it is packed into a container image with all its essential dependencies. A container, always created from a container image, provides a disposable and isolated runtime environment for its application. Containerized software behaves the same way in different host environments. Usually, a container image is built from a text-based and human-readable definition file that notably improves the manageability of the environment.
The aim of this thesis was to determine the feasibility of using Windows containers as the runtime environment of Setup Builder. The first goal was to investigate whether it is possible to install the build tools in a container image, and eventually run Setup Builder in the container. The second goal was to benchmark the performance impact of containerization. The execution time and resource usage of containerized Setup Builder were not allowed to increase above the acceptable limits.
Within the thesis, the container image was created successfully. It provided functional environment for Setup Builder. The build execution was normal, repeatable and stable inside the container. Nonetheless, numerous challenges were encountered during the early parts of the container image implementation. Due to the challenges, the implementation required notably more working hours than planned. It seems that challenges might be possible or even likely when a Windows-based application is containerized. The occurrence of issues depends heavily on the tools needed in the container image.
At the end, Setup Builder was benchmarked. The performance measurements were done for a few different cases. Windows containers support two isolation modes, process isolation and Hyper-V isolation, or virtual machine isolation in a technology neutral manner. With the latter mode, the container is run in a lightweight and highly optimized utility virtual machine. Both modes were benchmarked. M-Files had a local computational grid that accelerated code compilation. The benchmark included cases, when the grid was used, and cases, when it was not used.
According to the benchmark, process isolated Windows containers are an excellent choice as a build environment for a monolithic software that resembles M-Files. The execution time of Setup Builder increased less than 10 % in process isolation with and without the help of the local grid. Processor usage or memory consumption did not change much in process isolation.
Virtual machine isolated Windows-containers yielded poor results in the benchmark. The execution time and memory usage of Setup Builder increased vastly in virtual machine isolated containers. The initial assumption was that the local grid might decrease the performance impact, as part of the most intense work is delegated to the grid. As a contrary to the expectations, the negative performance impact was increased when the grid was used. That said, it might be possible to improve the degraded performance if bottlenecks are identified and fixed.
Kontitus nähtiin yhtenä ratkaisuna, jolla palvelinten ylläpitotaakka olisi vähennettävissä. Kaikki koontipalvelimilla ajetut tehtävät haluttiin kontittaa. Tulevaisuuden tavoite oli, että kontitetut tehtävät ajettaisiin pilvessä, jolloin paikallisista palvelimista voitaisiin luopua. Konttiin käärityt tehtävät olisi helpompi siirtää pilviympäristöön.
Kontitus on suosittu ja kevyt virtualisointiteknologia. Kontituksessa on kyse siitä, että ohjelmisto ja kaikki sen riippuvuudet paketoidaan konttikuvaan. Kontti on kertakäyttöinen ajoympäristö, joka luodaan konttikuvasta ja jossa ohjelmisto toimii aina samalla tavalla. Konttikuvat rakennetaan tekstipohjaisen määrittelytiedoston pohjalta, joka on ihmisen luettavassa muodossa. Ohjelmiston ajoympäristö on hallittavissa helposti ja tehokkaasti konttikuvana ja sen määrittelytiedostona.
Tässä diplomityössä selvitettiin, soveltuvatko Windows-kontit Setup Builderin ajoympäristöksi. Kaikkien käytettyjen kehitys- ja koontityökalujen oli asennuttava konttiin ja toimittava normaalisti. Setup Builderin tuli olla ajettavissa kontissa loppuun asti. Myös suorituskykyvaikutusten selvitys nähtiin tärkeänä. Setup Builderin suoritusaika ja resurssienkäyttö eivät saaneet kasvaa liikaa kontissa.
Diplomityössä toteutettiin onnistuneesti konttikuva, josta luodussa kontissa Setup Builder oli ajettavissa normaalisti, toistettavasti ja vakaasti. Konttikuvan toteutuksen alkupuolella kohdattiin kuitenkin useita ongelmia. Toteutukseen kului moninkertaisesti odotettua enemmän aikaa. Windows-pohjaisten sovellusten kontituksessa on varauduttava ongelmanratkontaan. Ongelmien esiintymiseen vaikuttaa oleellisesti se, mitä työkaluja konttiin on asennettava.
Lopussa kontitetulle Setup Builderille tehtiin suorituskykymittaukset. Mittauksiin liittyi useita mittaustapauksia. Windows-kontteja voi ajaa kahdella vaihtoehtoisella eristystasolla, prosessieristyksessä ja Hyper-V-eristyksessä, jota kutsuttiin teknologianeutraalimmin virtuaalikone-eristykseksi. Jälkimmäinen eristystaso on hybridiratkaisu, jossa konttia ajetaan pitkälle optimoidussa ja kevyessä utiliteettivirtuaalikoneessa. M-Filesillä oli oma, paikallinen laskentaverkko, joka nopeutti komponenttien kääntämistä. Mittaukset suoritettiin erikseen tapauksille, joissa laskentaverkko avustaa koontia, ja tapauksille, jossa laskentaverkkoa ei käytetä.
Tulosten perusteella prosessieristetyt Windows-kontit soveltuvat erinomaisesti M-Filesin kaltaisen laajan ohjelmiston koontialustaksi. Setup Builderin suoritusaika kasvoi vähemmän kuin 10 % riippumatta siitä, käytettiinkö laskentaverkkoa. Muistinkulutus ja suorittimenkäyttö eivät muuttuneet oleellisesti prosessieristetyssä kontissa.
Virtuaalikone-eristetyt Windows-kontit eivät menestyneet mittauksissa. Setup Builderin suoritusaika ja muistinkulutus lisääntyivät valtavasti. Alussa oletettiin, että laskentaverkon käyttö vähentäisi virtuaalikone-eristyksen vaikutusta koonnin suorituskykyyn, koska osa raskaasta käännöstyöstä on delegoitu laskentaverkolle. Oletuksen vastaisesti suorituskykyvaikutukset korostuivat laskentaverkkoa käytettäessä. Virtuaalikone-eristyksen negatiiviset suorituskykyvaikutukset saattavat olla kuitenkin vähennettävissä tunnistamalla ja poistamalla pullonkaulat.
Containerization was seen as a solution to the maintenance burden. We wanted to containerize each task hosted on the build servers. The future plan was to retire the local servers and run the tasks on a cloud environment. The transition would be easier with containerized tasks.
Containerization is a widespread and lightweight virtualization technology. When an application is containerized, it is packed into a container image with all its essential dependencies. A container, always created from a container image, provides a disposable and isolated runtime environment for its application. Containerized software behaves the same way in different host environments. Usually, a container image is built from a text-based and human-readable definition file that notably improves the manageability of the environment.
The aim of this thesis was to determine the feasibility of using Windows containers as the runtime environment of Setup Builder. The first goal was to investigate whether it is possible to install the build tools in a container image, and eventually run Setup Builder in the container. The second goal was to benchmark the performance impact of containerization. The execution time and resource usage of containerized Setup Builder were not allowed to increase above the acceptable limits.
Within the thesis, the container image was created successfully. It provided functional environment for Setup Builder. The build execution was normal, repeatable and stable inside the container. Nonetheless, numerous challenges were encountered during the early parts of the container image implementation. Due to the challenges, the implementation required notably more working hours than planned. It seems that challenges might be possible or even likely when a Windows-based application is containerized. The occurrence of issues depends heavily on the tools needed in the container image.
At the end, Setup Builder was benchmarked. The performance measurements were done for a few different cases. Windows containers support two isolation modes, process isolation and Hyper-V isolation, or virtual machine isolation in a technology neutral manner. With the latter mode, the container is run in a lightweight and highly optimized utility virtual machine. Both modes were benchmarked. M-Files had a local computational grid that accelerated code compilation. The benchmark included cases, when the grid was used, and cases, when it was not used.
According to the benchmark, process isolated Windows containers are an excellent choice as a build environment for a monolithic software that resembles M-Files. The execution time of Setup Builder increased less than 10 % in process isolation with and without the help of the local grid. Processor usage or memory consumption did not change much in process isolation.
Virtual machine isolated Windows-containers yielded poor results in the benchmark. The execution time and memory usage of Setup Builder increased vastly in virtual machine isolated containers. The initial assumption was that the local grid might decrease the performance impact, as part of the most intense work is delegated to the grid. As a contrary to the expectations, the negative performance impact was increased when the grid was used. That said, it might be possible to improve the degraded performance if bottlenecks are identified and fixed.