= Docker and docker-compose
Thomas W. Stütz
1.0.0, 2021-03-24: How to use Docker in project work @ HTL Leonding college
ifndef::imagesdir[:imagesdir: images]
//:toc-placement!:  // prevents the generation of the doc at this position, so it can be printed afterwards
:sourcedir: ../src/main/java
:icons: font
:sectnums:    // Nummerierung der Überschriften / section numbering
:toc: left
:toclevels: 5
:experimental: true
:linkattrs:   // so window="_blank" will be executed

//Need this blank line after ifdef, don't know why...
ifdef::backend-html5[]

// https://fontawesome.com/v4.7.0/icons/
icon:file-text-o[link=https://raw.githubusercontent.com/htl-leonding-college/docker-lecture-notes/main/asciidocs/{docname}.adoc] ‏ ‏ ‎
icon:github-square[link=https://github.com/htl-leonding-college/docker-lecture-notes] ‏ ‏ ‎
icon:home[link=http://edufs.edu.htl-leonding.ac.at/~t.stuetz/hugo/2021/01/technology-notes/]
endif::backend-html5[]

// print the toc here (not at the default position)
//toc::[]

//image:maintenance_640.jpg[link="https://pixabay.com/illustrations/maintenance-under-construction-2422172/", width=60%, window="_blank"]

image:under-construction-640.png[link="https://pixabay.com/illustrations/under-construction-construction-sign-2408062/", width=60%, window="_blank"]

//image:sign-work-in-progress.png[link="https://pixabay.com/vectors/work-under-construction-98936/", width=60%, window="_blank"]

This page is still under construction



== Docker - Grundlagen - Running a Container

<<docker.adoc#bookmark-document-start,Docker>>


== Create a Docker Image

<<dockerfile.adoc#_create_a_docker_image,Create a Docker image>>


== docker-compose

<<docker-compose.adoc#bookmark-document-start,docker-compose>>


== Deployment

<<docker-deployment.adoc#bookmark-document-start,Deployment of Docker Container>>



== sources

* https://devopscube.com/category/docker/[devopscube - browsing categrory - docker^]
* https://devopscube.com/build-docker-image/[Dockerfile Explained]

* alt, aber gut
+
++++
<iframe width="560" height="315" src="https://www.youtube.com/embed/pTFZFxd4hOI" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
++++



== [deprecated]

<<docker-jenkins.adoc#bookmark-document-start,Docker and Jenkins>>

<<schilf-stropek-2020-10-12.adoc#bookmark-document-start,schilf-stropek-2020-10-12>>





////

----
Credits to Mr. Christian Aberger - this notes are based on his lecture @ HTL Leonding
----

== Continous Integration vs Delivery vs Deployment

* Source: https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment

=== Continuous Integration

Developers practicing continuous integration merge their changes back to the main branch as often as possible. The developer's changes are validated by creating a build and running automated tests against the build. By doing so, you avoid integration challenges that can happen when waiting for release day to merge changes into the release branch.

Continuous integration puts a great emphasis on testing automation to check that the application is not broken whenever new commits are integrated into the main branch.

=== Continuous Delivery

Continuous delivery is an extension of continuous integration since it automatically deploys all code changes to a testing and/or production environment after the build stage.

This means that on top of automated testing, you have an automated release process and you can deploy your application any time by clicking a button.

In theory, with continuous delivery, you can decide to release daily, weekly, fortnightly, or whatever suits your business requirements. However, if you truly want to get the benefits of continuous delivery, you should deploy to production as early as possible to make sure that you release small batches that are easy to troubleshoot in case of a problem.

=== Continuous Deployment

Continuous deployment goes one step further than continuous delivery. With this practice, every change that passes all stages of your production pipeline is released to your customers. There's no human intervention, and only a failed test will prevent a new change to be deployed to production.

Continuous deployment is an excellent way to accelerate the feedback loop with your customers and take pressure off the team as there isn't a Release Day anymore. Developers can focus on building software, and they see their work go live minutes after they've finished working on it.

.https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment[Source: www.atlassian.com]
image:ci-cd-cd-atlassian.png[]

== Overview - What we will do!

. Create a Quarkus app providing a simple restful endpoint.
. This app will be pushed automatically to github
. Prepare the remote server for deploying the quarkus app (we will use an oracle vm instance)
. Create the gh-actions pipeline
. Create a service for starting the quarkus-app on the remote server

== Creating a Virtual Maschine Instance in Oracle Cloud

<<create-oravm.adoc#,Creating a Virtual Maschine Instance in Oracle Cloud>>


== Create a Simple Quarkus Application

<<create-quarkus-app.adoc#,Create a Quarkus Application>>

== Create a Continous Delivery Pipeline in gh-actions

<<gh-actions.adoc#,Create a yml-File>>

////

