{"id":4405,"date":"2019-01-04T20:19:32","date_gmt":"2019-01-04T19:19:32","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=4405"},"modified":"2023-06-09T14:23:27","modified_gmt":"2023-06-09T12:23:27","slug":"radcup-part-3-automation","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2019\/01\/04\/radcup-part-3-automation\/","title":{"rendered":"Radcup Part 3 – Automation with Gitlab CI\/CD"},"content":{"rendered":"\n

Written by: Immanuel Haag, Christian M\u00fcller, Marc R\u00fcttler<\/p>\n\n\n\n

The goal of this blog entry is to automate the previously performed steps. At the end all manual steps should be automated when new code changes are added to the repository. The new version of the backend will be made available in the cloud at the end.
<\/p>\n\n\n\n\n\n\n\n

Step 1: Gitlab Repository Setup<\/h2>\n\n\n\n

The first step was to automate the manual execution of testing, image creation and deployment. Especially to prevent mistakes and to define a standardized procedure. We used the external hosted service of gitlab.com<\/a> instead of the Medienhochschule Stuttgart GitLab. The reason for this is that mi.gitlab pipelines may have some strange behavior when connecting to external IP ranges. Therefore we have created a new repository under the following link: https:\/\/gitlab.com\/system_eng_cup_app\/radcup_backend<\/a> (if you are interested, please contact us, because the project is private). In addition, we decided to use the Git Feature Branch Workflow<\/a> for development. This results in many commits as well as several branches (background: there should not be one large but several small commits for customization’s). <\/p>\n\n\n\n

To push images into the container registry or to deploy them in the cluster, different passwords or tokens are needed. These must not appear in plain text in the pipeline definition. For this reason these are stored under the CI\/CD settings and are called via variable names.
<\/p>\n\n\n\n

Step 2: Define the architecture <\/h2>\n\n\n\n

After the repository and pipeline were created, we had to think about a rough architecture for our system. The following picture shows a simplified version of this: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Step 3: Gitlab CI\/CD Setup<\/h2>\n\n\n\n

We defined multiple stages to divide the pipeline into multiple steps.
These are based on the steps previously performed manually as described above. Note: In gitlab you have to turn on the CI\/CD Feature in the repository settings. <\/em><\/p>\n\n\n\n

The pipeline stages<\/h4>\n\n\n\n

Our pipeline has the following stages:<\/p>\n\n\n\n

  1. imagegen<\/li>
  2. test<\/li>
  3. build<\/li>
  4. deploy<\/li>
  5. curlcluster<\/li><\/ol>\n\n\n\n

    .gitlab-ci.yml and runners<\/h4>\n\n\n\n

    In short, this file defines how the project should be built by the GitLab Runner. It must be located in the root directory of the GitLab repository.<\/p>\n\n\n\n

    We found the Gitlab Documentation<\/a> helpful.
    And the     quick start quide<\/a>, which is also referenced in the documentation, was also interesting.<\/a><\/p>\n\n\n\n

    To get the pipeline running only the mentioned file has to be present and a GitLab Runner has to be configured.<\/p>\n\n\n\n

    Please note that the file does not configure the whole project with all branches and throughout all commits. This file is also version controlled like any other file in the repository, which means that this file could be different for every commit and on every branch. We decided to keep this file uniform on all branches.
    Interesting notes<\/a>.<\/a><\/p>\n\n\n\n

    We use the free, open for everyone “Shared Runners”. Runners can be configured via the website under “Settings” -> “CI \/ CD” -> “Runners”. Own Runners can also be configured there. Now every push\/commit to the repository will cause the pipeline to run.<\/p>\n\n\n\n

    During development, there was often the problem of delays, so a dedicated runner was set up for longer debugging sessions. Feel free to consolidate the docs for more information about a separated runner.<\/p>\n\n\n\n

    If any job\/stage returns a non zero value, the job will be interpreted as failed only if everything returns zero it will be considered passed.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    In the Picture one can see that on a commit two jobs passed and one failed. The failed job caused the whole pipeline to fail as expected. Also note that subsequent jobs were skipped an not even attempted.<\/p>\n\n\n\n

    In the following sections the setup of each stage in this file is described.<\/p>\n\n\n\n

    stages, variables and before_script<\/h4>\n<\/div>\n\n\n\n
    stages:<\/span>\n-<\/span> imagegen\n-<\/span> test\n-<\/span> build\n-<\/span> deploy\n-<\/span> curlcluster\n\nvariables:<\/span>\n  MAJOR:<\/span> '1'<\/span>\n  MINOR:<\/span> '1'<\/span>\n  PATCH:<\/span> '1'<\/span>\n  CLUSTERURL:<\/span> '159.122.181.248:30304'<\/span>\n  \nbefore_script:<\/span>\n  -<\/span> export BUILD_REF=`export TERM=xterm; git log --pretty=format:'%h'<\/span> -n 1<\/span>`\n  -<\/span> export IMAGE_TAG=`export TERM=xterm;  date +%Y%m%d_%H%M`\n  -<\/span> export BUILD_TAG=${MAJOR}.${MINOR}.${PATCH}-build.${BUILD_REF}\n<\/pre>\n\n\n\n
    Description:<\/strong><\/p>\n\n\n\n
    Variables<\/em>:<\/p>\n
    The variable section is used to introduce the so-called semantic versioning. This gives developers the advantage of listing the current version of the backend in individual sub-releases and can be considered as best practice. Details about that are shown under the following link: https:\/\/semver.org\/<\/a>.
    \nFor example if a developer fixes a small issue he has to increment the PATCH<\/code> variable by one.<\/p>\n<\/div>\n\n\n\n
    Before the pipeline starts executing, multiple variables are generated and exported in the before_script<\/em> section. This part was inserted later because code duplications were available before.<\/p>\n
    For later image name tagging in the build-stage BUILD_REF<\/code> and BUILD_TAG<\/code> creates a string from the semantic-versioning variables and the latest commit id like this:<\/p>\n
    Successfully tagged registry.eu-de.bluemix.net\/system_engineering_radcup\/radcup_backend:1.1.1-build.b5ecee4\ufeff<\/strong><\/p>\n<\/div>\n\n\n\n
    The BUILD_TAG<\/code> variable is used in the imagegen<\/em> stage. This construct creates a nametag like 20190106_1929<\/code> which represent the creation date of the immae1\/ibmcloudkubectl<\/code> image. Details about that are described below.<\/p>\n<\/div>\n\n\n\n
    1. imagegen stage<\/h4>\n\n\n\n
    imagegen:<\/span>\n  image:<\/span> immae1\/ibmcloudkubectl # we use this image because here is git installed<\/span>\n  services:<\/span>\n  - docker:<\/span>dind\n  stage:<\/span> imagegen\n  only:<\/span>\n    -<\/span> image_gen\n  script:<\/span>\n  -<\/span> docker login --username ${DOCKERH_USR} --password ${DOCKERH_PWD}\n  -<\/span> cd ibmcloudkubectlimage\/; docker build -t immae1\/ibmcloudkubectl:latest . ; docker push immae1\/ibmcloudkubectl:latest ; docker tag immae1\/ibmcloudkubectl:latest immae1\/ibmcloudkubectl:${IMAGE_TAG} ; docker push immae1\/ibmcloudkubectl:${IMAGE_TAG} \n  environment:<\/span>\n    name:<\/span> imagegen\n<\/pre>\n\n\n\n
    Description:<\/strong><\/p>\n\n\n\n
    The build<\/em> and deploy<\/em> stage require some tools for their doing. So we created the imagegen<\/em> stage. This stage is responsible for creating a "default tooling-image".<\/p>\n
    The only<\/code> keyword is used because only the imagegen branch of our repository is responsible for this stage and image generation. As we have no control over updates of the CLI tools which are installed in the image, we choose a decoupled approach. And the imagegen branch is executed by the gitlab schedules feature, on every Sunday.<\/p>\n
    Below you can see the Dockerfile in which is defined that the IBM-Cloud CLI-Tools<\/code> and kubectl<\/code> are installed.<\/p>\n<\/div>\n\n\n\n
    FROM<\/span> docker:latest\nRUN<\/span> apk add --update --no-cache curl git ca-certificates \\\n&& apk add --update -t deps curl \\\n&& apk add --update gettext \\\n&& curl -fsSL https:\/\/clis.ng.bluemix.net\/install\/linux | sh \\\n&& ibmcloud plugin install container-registry \\\n&& ibmcloud plugin install container-service \\\n&& curl -LO https:\/\/storage.googleapis.com\/kubernetes-release\/release\/$(curl -s<\/span> https:\/\/storage.googleapis.com\/kubernetes-release\/release\/stable.txt)\/bin\/linux\/amd64\/kubectl  \\\n&& chmod +x .\/kubectl \\\n&& mv .\/kubectl \/usr\/local<\/span>\/bin\/kubectl \\\n&& apk del --purge deps \\\n&& rm \/var\/cache\/apk\/*<\/span><\/pre>\n\n\n\n
    Finding: <\/p>\n\n\n\n
    It was not easy to update an image within the dockerhub. But the trick is to tag twice whilst creating the image with latest<\/em> and the current date<\/em>. So after a second image creation and pushing, the are different versions of our image available in the dockerhub.<\/p>\n\n\n\n
    2. test stage<\/h4>\n\n\n\n
    test:<\/span>\n  image:<\/span> node:jessie\n  services:<\/span>\n  - name:<\/span> mongo:4.0<\/span>\n    alias:<\/span> mongo\n  stage:<\/span> test\n  except:<\/span>\n    -<\/span> image_gen\n  variables:<\/span>\n    MONGO_URI:<\/span> 'mongodb:\/\/mongo\/radtest'<\/span>\n    NODE_ENV:<\/span> test\n  script:<\/span>\n  -<\/span> cd src\/ && npm install --no<\/span>-optional && npm test\n  environment:<\/span>\n    name:<\/span> test<\/pre>\n\n\n\n
    Description:<\/strong><\/p>\n\n\n\n
    The test<\/em> stage is relativ straight forward. With the except<\/code> keyword its defined that this stage is not performed in the imagegen<\/em> branch. All other branches will perform this test stage. The other finding what we found here and is interesting to mention is the following fact. If you use shared gitlab runners, you never know which IP-Address a runner uses to talk with the internet. So if you want to use an external service like our managed external hosted MongoDB with IP-Whitelisting security feature you will encounter problems. Because of this the stage uses an additional local MongoDB container and the backend\/test-suite can talk to this new local MongoDB gitlab container trough the MONGO_URI<\/code> variable.<\/p>\n<\/div>\n\n\n\n
    3. build stage<\/h4>\n\n\n\n
    build:<\/span>\n  image:<\/span> immae1\/ibmcloudkubectl:latest # or another arbitrary docker image<\/span>\n  stage:<\/span> build\n  only:<\/span>\n    -<\/span> master\n  services:<\/span>\n  - docker:<\/span>dind\n  script:<\/span>\n    -<\/span> ibmcloud login -a https:\/\/api.eu-de.bluemix.net -u ${BLUEMIX_USR} -p ${BLUEMIX_PWD} -c ${BLUEMIX_ORG} && ibmcloud cr login\n    -<\/span> ibmcloud cr image-list --format \"{{ .Created}}<\/span> {{ if gt .Size 1 }}<\/span>{{ .Repository }}<\/span>:{{ .Tag }}<\/span> {{end}}<\/span>\"<\/span> | grep \"system_engineering_radcup\"<\/span> | sort -n | cut -c12-98<\/span> | head -n -1<\/span> >> deprecated.txt && chmod +x clean.sh && sh clean.sh deprecated.txt\n    -<\/span> docker build -t registry.eu-de.bluemix.net\/system_engineering_radcup\/radcup_backend:${BUILD_TAG} .\n    -<\/span> docker push registry.eu-de.bluemix.net\/system_engineering_radcup\/radcup_backend:${BUILD_TAG}\n  environment:<\/span>\n    name:<\/span> build<\/pre>\n\n\n\n
    Description:<\/strong><\/p>\n\n\n\n
    In this stage (is only executed on the master branch, see keyword only<\/code>), the image is built based on the corresponding dockerfile of our backend (see first post<\/a>). After the successful login, all images stored in the container registry are first read (the command output is formatted using the specified Go template), filtered and sorted, and the name of the oldest image is stored in a text file. This image is then deleted in the next step.<\/p>\n<\/div>\n\n\n\n
    \n
    Background:<\/p>\n
    A CleanUp process has been defined to prevent the container registry from overflowing. This process ensures that there are never more than two images in the container registry at the same time. Keyword: resource management.<\/p>\n<\/div>\n\n\n\nclean.sh\n
    #!\/bin\/bash<\/span>\nwhile<\/span> IFS= read<\/span> -r line; do<\/span>\n  ibmcloud cr image-rm $line<\/span>\ndone<\/span> < \"$1<\/span>\"<\/span>\n<\/pre>\n\n\n\n
    \n
    If the oldest image is deleted, a new one is built and tagged before it is pushed into the container registry.<\/p>\n<\/div>\n\n\n\n
    4. deploy stage<\/h4>\n\n\n\n
    deploy:<\/span>\n  image:<\/span> immae1\/ibmcloudkubectl:latest\n  stage:<\/span> deploy\n  only:<\/span>\n    -<\/span> master\n  script:<\/span>\n    -<\/span> ibmcloud login -a https:\/\/api.eu-de.bluemix.net -u ${BLUEMIX_USR} -p ${BLUEMIX_PWD} -c ${BLUEMIX_ORG_FREE} && ibmcloud cs region-set eu-central && ibmcloud cs cluster-config radcup\n    -<\/span> export KUBECONFIG=\/root\/.bluemix\/plugins\/container-service\/clusters\/radcup\/kube-config-mil01-radcup.yml\n    -<\/span> cd kubernetes\/ && sed -i s\/version-radcup\/${BUILD_TAG}\/g web-controller.yaml && kubectl get rc -o=custom-columns=NAME:.metadata.name > tmp.txt && sed -i '1d'<\/span> tmp.txt && RC=`cat tmp.txt`\n    -<\/span> kubectl rolling-update ${RC} -f web-controller.yaml\n  environment:<\/span>\n    name:<\/span> deploy<\/pre>\n\n\n\n
    Description:\ufeff<\/strong>
    <\/p>\n\n\n\n
    In this stage (is only executed on the master branch, see keyword only<\/code>), the previously built and pushed image is deployed in the cluster. After the successful login, the string version-radcup<\/code> is replaced by ${BUILD_TAG}<\/code> in the file web-controller.yaml<\/code>. Then all replication controllers in the cluster are read to get the name of the affected controller and store it in a variable (background: this part has been added because the name of the web-controller has partly changed throughout the project). Finally, a rolling update to the replication controller is performed with the help of this and the image is updated accordingly.<\/p>\n<\/div>\n\n\n\n
    \n
    Rolling update:<\/p>\n
    Rolling updates allow Deployment updates to take place with zero downtime by incrementally updating Pods instances with new ones.<\/p>\n
      \n
    • Example output:<\/li>\n<\/ul>\n<\/div>\n\n\n\n
      Created web-controller-1.1.1-build\nScaling up web-controller-1.1.1-build from 0 to 2, scaling down web-controller from 2 to 0 (keep 2 pods available, don't exceed 3 pods)\nScaling web-controller-1.1.1-build up to 1\nScaling web-controller down to 1\nScaling web-controller-1.1.1-build up to 2\nScaling web-controller down to 0\nUpdate succeeded. Deleting old controller: web-controller\nRenaming web-controller-1.1.1-build to web-controller<\/pre>\n\n\n\n
      \n<\/div>\n\n\n\n
      5. curlcluster stage<\/h4>\n\n\n\n
      curlcluster:<\/span>\n  stage:<\/span> curlcluster\n  only:<\/span>\n    -<\/span> master\n  script:<\/span>\n  -<\/span> result=\"$(curl -m2 http:\/\/${CLUSTERURL}\/api)\"<\/span>\n  -<\/span> should='{\"message\":\"this will be a beerpong app\"}'<\/span>\n  -<\/span> if [[ \"$result\"<\/span> != \"$should\"<\/span> ]] ; then exit 1<\/span>; fi\n  -<\/span> resultgame=\"$(curl -m2 http:\/\/${CLUSTERURL}\/api\/games\/5c2904bf172dbc0023ffdaea)\"<\/span>\n  -<\/span> shouldgame=`cat gameresult.txt `\n  -<\/span> if [[ \"$resultgame\"<\/span> != \"$shouldgame\"<\/span> ]] ; then exit 1<\/span>; fi\n  environment:<\/span>\n    name:<\/span> curlcluster<\/pre>\n\n\n\n
      Description:<\/strong><\/p>\n\n\n\n
      This stage (is only executed on the master branch, see keyword only<\/code>) is the last endpoint test. The cli tool curl<\/code> is used to make a http call against the before updated cluster. If the API is not available – the return code becomes 1<\/em> and because of that the stage will fail. We decided to also test if the api is connected to the mongodbcluster<\/em> – this is the second curl test which observes a unique gameid<\/em>. This game is present in the mongo database at all times, so that this test won’t fail.<\/p>\n<\/div>\n\n\n\n
      Step 4: The whole architecture <\/h2>\n\n\n\n
      After the integration of the CI\/CD pipeline described above, we can now present the entire architecture of our system. This can be seen in the following picture:<\/p>\n\n\n\n
      \"\"<\/figure>\n\n\n\n
      Step 5: Research questions and further project steps <\/h2>\n\n\n\n
        \n
      • Scan images for vulnerabilities and challenge application logic (API vulnerability)<\/li>\n
      • Eliminate pipeline warnings (rollout for rolling update, credential manager for docker login in imagegen stage)<\/li>\n
      • Changing the ReplicationController to a ReplicaSet (newer version of the ReplicationController)<\/li>\n
      • Endpoint testing and load testing should be pursued further<\/li>\n
      • Set up Hooks in Slack etc.<\/li>\n
      • Apply 12-Factorapp principles to the project<\/li>\n
      • Further improve and simplify the pipeline<\/li>\n
      • Automate npm-check<\/li>\n<\/ul>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
        Written by: Immanuel Haag, Christian M\u00fcller, Marc R\u00fcttler The goal of this blog entry is to automate the previously performed steps. At the end all manual steps should be automated when new code changes are added to the repository. The new version of the backend will be made available in the cloud at the end.<\/p>\n","protected":false},"author":884,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[659,650,651,2],"tags":[206,144,7,210,61,3,97,98,145,154],"ppma_author":[762],"class_list":["post-4405","post","type-post","status-publish","format-standard","hentry","category-devops","category-scalable-systems","category-system-designs","category-system-engineering","tag-beerpong","tag-ci-pipeline","tag-cloud","tag-cluster","tag-containers","tag-docker","tag-git","tag-gitlab","tag-gitlab-ci","tag-kubernetes"],"aioseo_notices":[],"jetpack_featured_media_url":"","jetpack-related-posts":[{"id":3348,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2018\/03\/30\/continuous-integration-pipeline-for-unity-development-using-gitlab-ci-and-aws\/","url_meta":{"origin":4405,"position":0},"title":"Continuous Integration Pipeline for Unity Development using GitLab CI and AWS","author":"Jonas Graf, Christian Gutwein","date":"30. March 2018","format":false,"excerpt":"This blog entry describes the implementation of a Continous Integration (CI) pipeline especially adapted for Unity projects. It makes it possible to automatically execute Unity builds on a configured build server and provide it for a further deployment process if required.","rel":"","context":"In "DevOps"","block_context":{"text":"DevOps","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/scalable-systems\/devops\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/03\/CI_process.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/03\/CI_process.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/03\/CI_process.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/03\/CI_process.png?resize=700%2C400&ssl=1 2x"},"classes":[]},{"id":5179,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2019\/02\/24\/migrating-to-kubernetes-part-4-create-environments-via-gitlab\/","url_meta":{"origin":4405,"position":1},"title":"Migrating to Kubernetes Part 4 – Create Environments via Gitlab","author":"Can Kattwinkel","date":"24. February 2019","format":false,"excerpt":"Written by: Pirmin Gersbacher, Can Kattwinkel, Mario Sallat Connect Gitlab with Kubernetes With the Review Apps Gitlab offers an excellent improvement of the Developer Experience. More or less Gitlab enables the management of environments. For each environment, there is a CI task to each set-up and tear down. It is\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/02\/pexels-photo-379964.jpeg?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/02\/pexels-photo-379964.jpeg?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/02\/pexels-photo-379964.jpeg?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/02\/pexels-photo-379964.jpeg?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/02\/pexels-photo-379964.jpeg?resize=1050%2C600&ssl=1 3x"},"classes":[]},{"id":7154,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2019\/08\/31\/setting-up-a-ci-cd-pipeline-in-gitlab\/","url_meta":{"origin":4405,"position":2},"title":"Setting up a CI\/CD pipeline in Gitlab","author":"nr037","date":"31. August 2019","format":false,"excerpt":"Introduction For all my university software projects, I use the HdM Gitlab instance for version control. But Gitlab offers much more such as easy and good ways to operate a pipeline. In this article, I will show how we can use the CI\/CD functionality in a university project to perform\u2026","rel":"","context":"In "Cloud Technologies"","block_context":{"text":"Cloud Technologies","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/scalable-systems\/cloud-technologies\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/08\/Screenshot-2019-08-26-at-09.53.13.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/08\/Screenshot-2019-08-26-at-09.53.13.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/08\/Screenshot-2019-08-26-at-09.53.13.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/08\/Screenshot-2019-08-26-at-09.53.13.png?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/08\/Screenshot-2019-08-26-at-09.53.13.png?resize=1050%2C600&ssl=1 3x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/08\/Screenshot-2019-08-26-at-09.53.13.png?resize=1400%2C800&ssl=1 4x"},"classes":[]},{"id":3513,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2018\/03\/30\/ci-cd-with-gitlab-ci-for-a-web-application-part-3\/","url_meta":{"origin":4405,"position":3},"title":"CI\/CD with GitLab CI for a web application – Part 3","author":"Nina Schaaf","date":"30. March 2018","format":false,"excerpt":"Hosting your own GitLab server Some users might have concerns regarding security using GitLab for a variety of purposes, including commercial and business applications. That is, because GitLab is commonly used as a cloud-based service - on someone else's computer, so to speak. So setting it up for running it\u2026","rel":"","context":"In "DevOps"","block_context":{"text":"DevOps","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/scalable-systems\/devops\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":21064,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2021\/09\/11\/how-do-you-get-a-web-application-into-the-cloud\/","url_meta":{"origin":4405,"position":4},"title":"How do you get a web application into the cloud?","author":"af094","date":"11. September 2021","format":false,"excerpt":"by Dominik Ratzel (dr079) and Alischa Fritzsche (af094) For the lecture \"Software Development for Cloud Computing\", we set ourselves the goal of exploring new things and gaining experience. We focused on one topic: \"How do you get a web application into the cloud?\". In doing so, we took a closer\u2026","rel":"","context":"In "Cloud Technologies"","block_context":{"text":"Cloud Technologies","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/scalable-systems\/cloud-technologies\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/09\/availableRunners-150x118.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":3491,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2018\/03\/31\/continuous-integration-deployment-for-a-cross-platform-application-part-2\/","url_meta":{"origin":4405,"position":5},"title":"Continuous Integration & Deployment for a Cross-Platform Application – Part 2","author":"Tobias Eberle, Marco Maisel, Tobias Staib, Mario Walz","date":"31. March 2018","format":false,"excerpt":"In the first part we pointed out how we set up the infrastructure for our CI system. Now we would like to explain how we build a pipeline for our cross-platform application and what features of GitLab CI we made use of. Building a Pipeline in GitLab CI Our first\u2026","rel":"","context":"In "DevOps"","block_context":{"text":"DevOps","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/scalable-systems\/devops\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/03\/flora-app.jpg?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/03\/flora-app.jpg?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/03\/flora-app.jpg?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/03\/flora-app.jpg?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/03\/flora-app.jpg?resize=1050%2C600&ssl=1 3x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/03\/flora-app.jpg?resize=1400%2C800&ssl=1 4x"},"classes":[]}],"jetpack_sharing_enabled":true,"authors":[{"term_id":762,"user_id":884,"is_guest":0,"slug":"ih038","display_name":"Immanuel Haag","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/3095f100f75fe977c838303e854bb8cd3ffc7fbf01963610781fcd51bb5a4680?s=96&d=mm&r=g","0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""}],"_links":{"self":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/4405","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/users\/884"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/comments?post=4405"}],"version-history":[{"count":94,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/4405\/revisions"}],"predecessor-version":[{"id":5088,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/4405\/revisions\/5088"}],"wp:attachment":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/media?parent=4405"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/categories?post=4405"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/tags?post=4405"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/ppma_author?post=4405"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
    The result of this stage is online under the following link available: https:\/\/hub.docker.com\/r\/immae1\/ibmcloudkubectl<\/a>
    <\/p>\n\n\n\n