bezahlt von Composer Installation mit Version
Lösung:
php composer-setup.php --version=1.10.17
anstelle von
php composer-setup.php
Blog: Blog-entries by search-pattern/Tags:Lösung:
php composer-setup.php --version=1.10.17
anstelle von
php composer-setup.php
PHP-Build images für GitLab-CI
Die Images sind dafür gebaut in der Build-Stage von GitLab-CI PHP-Projekte zu bauen.
Traefik + Gitlab-CI: Autodeployment
Ich hatte die Idee einen kleinen Docker-Container laufen zu lassen, auf den alle geparkten Domains zeigen und der nur eine kleine Info-Seite ausliefert. Weil das Projekt so schön übersichtlich ist und ich gerne schnell und einfach neue Domains hinzufügen will, ohne dann immer Container selbst stoppen und starten zu müssen, habe ich mich dazu entschieden hier mit Gitlab-CI ein automatisches Deployment zubauen. Mein Plan war es ein Dockerfile zu haben, das mir das Image baut und bei dem per Label auch die Domains schon angegeben sind, die der Container bedienen soll. Wenn ich einen neuen Tag setze soll dieser das passende Image bauen und auf meinem Server deployen. Ich brauche dann also nur noch eine Datei anpassen und der Rest läuft automatisch.
Dafür habe ich mir dann extra einen Gitlab-Account angelegt. Man hat da alles was man braucht und 2000 Minuten auf Shared-Runnern. Mehr als genug für meine Zwecke.
Ich habe also eine index.html und ein sehr einfaches Dockerfile (docker/Dockerfile):
FROM httpd:2.4
COPY ./index.html /usr/local/apache2/htdocs/index.html
LABEL traefik.enable=true traefik.frontend.rule=Host:darknovels.de,www.darknovels.de
Das wird dann also in einen Job gebaut und in einem nach gelagerten auf dem Server deployed. Dafür braucht man einmal einen User auf dem Server und 2 Variablen in Gitlab für den Runner.
sudo adduser dockerupload
sudo usermod -aG docker dockerupload
Dann erzeugt man sich für den User einen Key (ohne Passphrase):
su dockerupload
ssh-keygen -t rsa
cp ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys
exit
Vielleicht muss man da noch die /etc/ssh/sshd_config editieren, damit die authorized_keys-Datei verwendet wird.
Den Private-Key einmal kopieren und in SSH_PRIVATE_KEY unter Settings - CI /DI - Variables speichern. Damit wir uns sicher vor Angriffen verbinden können müssen wir noch den Server zu den bekannten Hosts hinzufügen. Den Inhalt von known_hosts bekommt man durch:
ssh-keyscan myserver.com
Einfach den gesamten Output kopieren und in den Gitlab Variablen unter SSH_KNOWN_HOSTS speichern. Nun hat man alles was man braucht.
Jetzt folgt noch die .gitlab-ci.yml:
stages:
- build
- deploy
builddocker:
image: docker:git
stage: build
services:
- docker:dind
variables:
DOCKER_DRIVER: overlay
script:
- docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.gitlab.com
- docker build -t registry.gitlab.com/hpries/parkingpage:${CI_COMMIT_REF_SLUG} -f docker/Dockerfile .
- docker push registry.gitlab.com/hpries/parkingpage:${CI_COMMIT_REF_SLUG}
only:
- tags
pushtoserver:
image: kroniak/ssh-client:3.6
stage: deploy
script:
- mkdir ~/.ssh
- echo "$SSH_KNOWN_HOSTS" >> ~/.ssh/known_hosts
- chmod 644 ~/.ssh/known_hosts
- eval "$(ssh-agent -s)"
- ssh-add <(echo "$SSH_PRIVATE_KEY")
- ssh dockerupload@hannespries.de "docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.gitlab.com"
- ssh dockerupload@hannespries.de "docker stop pageparking" || true
- ssh dockerupload@hannespries.de "docker rm pageparking" || true
- ssh dockerupload@hannespries.de "docker rmi registry.gitlab.com/hpries/pageparking:${CI_COMMIT_REF_SLUG}" || true
- ssh dockerupload@hannespries.de "docker run --name pageparking --network=web -d registry.gitlab.com/hpries/pageparking:${CI_COMMIT_REF_SLUG}"
only:
- tags
CI_BUILD_TOKEN muss nicht gesetzt werden, sondern wird direkt von Gitlab bereit gestellt.
Einen Tag setzten, dann etwas warten, dann liegt hinter der Domain die index.html und ist direkt schon über HTTPS erreichbar.
Geht ziemlich schnell und einfach.. wenn man gute Beispiele hat! Sind wir nicht alle etwas DevOps?
Ein Docker-Image CI-Script für GitLab
Mit diesem Script werden der Master und alle Tags als Docker-Image gebaut, wobei der Master dann auch als latest-Tag abgelegt wird. D.h. der Master muss immer stable sein.. bei jedem Commit.
image: docker:latest
services:
- docker:dind
stages:
- build
- release
variables:
BUILD_IMAGE: gitlab.example.com:5555/sammy/hello_hapi:$CI_COMMIT_REF_NAME
RELEASE_IMAGE: gitlab.example.com:5555/sammy/hello_hapi:latest
before_script:
- docker login -u gitlab-ci-token -p $CI_JOB_TOKEN gitlab.example.com:5555
build_master_and_tags:
stage: build
script:
- docker build --pull -t $BUILD_IMAGE .
- docker push $BUILD_IMAGE
only:
- master
- tags
release_latest:
stage: release
script:
- docker pull $BUILD_IMAGE
- docker tag $BUILD_IMAGE $RELEASE_IMAGE
- docker push $RELEASE_IMAGE
only:
- master
Alternative kann man auch sich auf verschiedene Tags-Notationen einigen, wobei nur die Tags als latest getaggt werden, wenn diese ein release-Tag sind. Hier muss man aufpassen, falls man eine alte Version
nachträglich einpflegen will.
image: docker:latest
services:
- docker:dind
stages:
- build
- release
variables:
BUILD_IMAGE: gitlab.example.com:5555/sammy/hello_hapi:$CI_COMMIT_REF_NAME
RELEASE_IMAGE: gitlab.example.com:5555/sammy/hello_hapi:latest
before_script:
- docker login -u gitlab-ci-token -p $CI_JOB_TOKEN gitlab.example.com:5555
build_tags:
stage: build
script:
- docker build --pull -t $BUILD_IMAGE .
- docker push $BUILD_IMAGE
only:
- tags
release_latest:
stage: release
script:
- docker pull $BUILD_IMAGE
- docker tag $BUILD_IMAGE $RELEASE_IMAGE
- docker push $RELEASE_IMAGE
only:
- /^release-.*$/
except:
- branches