Biliyorsunuz CentOS 7 bugün EOL oldu ve kullanılamıyor. Geliştirme süreçlerinde ise hızlı aksiyon almanız gerekiyorsa ve hali hazırda kullandığınız yazılıma güncelleme gelmediyse aşağıdaki işlemleri yapın.

Hatadan örnek vermem gerekirse

1. centos-sclo-rh paketini bulamıyor
2. direk olarak mirrorliste erişemiyor.

Docker’da en kolay çözüm yöntemi ise şu şekilde kullanabilirsiniz.

# Workaround the fact that CentOS 7 is EOL
RUN sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-* \
  && sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-* \
  && yum-config-manager --disable centos-sclo-rh \
  && yum install epel-release -y

docker compose kurulumlarda çok fazla kullanılıyor pratikte çokta işe yarıyor ama zaman zaman hataya düşebiliyor, bir işlem yapıyorsunuz ve çakışmalara, aynı ağ adlarını almaya başlıyor.

Bu durumda docker güncellemelerinde ve/veya sistem güncellemelerinden sonra ortaya çıkıyor. Ağların ve konteyner’ların başlamasına engel oluyor.

Örnek bir hata mesajı

Sep 01 18:30:15 debian docker compose[2281641]: Removing network mertcan_default
Sep 01 18:30:15 debian docker compose[2281641]: network mertcan_default is ambiguous (2 matches found based on name)
Sep 01 18:30:16 debian systemd[1]: mertcan_default.service: Control process exited, code=exited, status=1/FAILURE

Aşağıdaki gibi yazdığımız ufacık bir python kodu ile sistemden başa bela olan bu ağları otomatik kaldırma işlemi yapabilirsiniz.

import subprocess
import json
import logging

logger = logging.getLogger(__name__)

output = subprocess.check_output(["docker", "network", "ls", "--format", "{{json .}}"])
networks = set()  # use a set to avoid duplicates

for line in output.decode("utf-8").splitlines():
    # check line is not empty
    if not line:
        logger.debug("Empty line found in docker network ls output (ignoring)")
        continue

    network = json.loads(line)
    if network["Name"] in networks:
        logger.info("Removing duplicate network: %s", network["Name"])
        subprocess.check_call(["docker", "network", "rm", network["Name"]])

    networks.add(network["Name"])

Bazı şeyleri otomatize ederken oto deployun yanı sıra otomatik güncelleme yapmakta önemli, bunun için rsync veya ssh üzerinden güncelleme yapmak yerine direk olarak docker containerı güncelleyebilirsiniz.

Bu işlem için ise direk olarak docker container build etmemiz bizim için yeterli, uygulamamız bunun içerisinde çalışacak ve watchtower bunu otomatik güncelleyecek.

İmaj oluşturmak için .gitlab-ci.yml için aşağıdaki yapılandırmayı kullanabilirsiniz.

image: docker:latest

docker-build:
  stage: build

  before_script:
    - docker info
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"

  variables:
    DOCKER_DRIVER: overlay2
    DOCKER_TLS_CERTDIR: "/certs"
    IMAGE_TAG: $CI_REGISTRY_IMAGE:latest

  script:
    - docker build -t "$IMAGE_TAG" .
    - docker push "$IMAGE_TAG"

Bu yapılandırma direk olarak mastera gönderilen her kodu container haline getirecek ve gitlab “container registry” içerisine basacak. Burada çift branch kullanmanızı öneririm. dev ve master olarak yoksa otomatik güncellemede sorunlarla karşılaşabilirsiniz.

Dockerfile yapılandırmamız ise aşağıdaki gibi, NodeJS uygulamamız çalışıyor siz kendinize göre güzel bir yapılandırma uygulayın.

FROM node:17

RUN set -eux; \
  npm install -g pm2

COPY app .

RUN npm install

CMD ["pm2-runtime", "index.js"]

İşlemler tamamlandığında imajımız gitlab’da duracak, isterseniz bu imajı docker hub üzerinede gönderebilirsiniz, karar size kalmış. Gitlab kullandığımız için biz başka bir alanda barındırmak istemedik.

Otomatik güncelleştirme kısmına geldik aşağıdaki gibi bir docker-compose.yml dosyası işimizi fazlasıyla görecek

version: "3.7"
services:
  monit:
    image: developer-core-team/monitoring_v01
    container_name: core_monitoring
    restart: always
  watchtower:
    image: containrrr/watchtower
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /root/.docker/config.json:/config.json
    command: --interval 30

Yapılandırmayı kendinize göre özelleştirmekte özgürsünüz 30 saniyede bir container registrymiz kontrol edilecek varsa güncelleme alınacak, isterseniz bu süreyi arttırabilirsiniz.

• https://github.com/containrrr/watchtower

Docker CLI ve Docker Compose ile ilgili sıkça kullandığım komutlar yer almaktadır. bu komutları terminal aracınıza kaydedip snippet olarak kullanabilirsiniz. Termius ve xShell üzerinde işlemlerinizi yapabilirsiniz.

Birden fazla geliştirme ortamı kullandığımız ve imajların güncelliğini yitirdiği senaryolar olabiliyor, mevcut bir konteyneri silmek istemeyebiliriz. Kullanılan bu konteyner production ortamında çalışıyor ve üzerinde işlem yapılıyor olabilir.

Docker kardeşimizde imajlar geçici olacak şekilde tasarlanmıştır. Yani mevcut bir imajı güncellemek için eskisini mecbur kaldırır ve yenisini başlatırsınız.

Bu işlemi yapmak için aşağıdaki prosedürü izlemeniz yeterlidir.

docker-compose pull
docker-compose up -d --remove-orphans
docker image prune -f

Bir imajın indirilmesinin başarısız olacağı senaryolar olabilir, kesintilerin sizin için önemli olacağı senaryolar olabilir. Bu sebeple tekrar imajı composer üzerinden pull etmeden ayağa kaldırma komutumuzu vermiyoruz. Güncel imajı indirmek ve bunun üzerinden tekrar konteyner ayağa kaldırmak bizim için önemli.

Gitea ile kendinize özgü kişiselleştirilmiş git sunucusu kurabilir, repolarınızı kendi bünyenizde barındırabilir siniz. Normalde kurulum biraz daha uzun ancak Docker kullanarak bu kurulumu sancısız atlatmak ve çok basit bir şekilde kullanmak mümkün

Resmi belgelendirmede paylaşılan docker-compose.yml dosyasının aksine ben uygulamayı lokalde çalıştırmayı seçtim ve dışarıya da NGINX ile açma yoluna gittim. Çalıştırmak için;

docker-compose up -d

Düzenlediğim dosya şu şekilde

version: "3"

networks:
  gitea:
    external: false

volumes:
  gitea:
    driver: local


services:
  server:
    image: gitea/gitea:latest
    container_name: gitea
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - DB_TYPE=postgres
      - DB_HOST=db:5432
      - DB_NAME=gitea
      - DB_USER=gitea
      - DB_PASSWD=change-me
    restart: always
    networks:
      - gitea
    volumes:
      - gitea:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "127.0.0.1:3000:3000"
      - "22:22"
    depends_on:
      - db

  db:
    image: postgres:latest
    restart: always
    environment:
      - POSTGRES_USER=gitea
      - POSTGRES_PASSWORD=change-me
      - POSTGRES_DB=gitea
    networks:
      - gitea
    volumes:
      - ./postgres:/var/lib/postgresql/data

Hemen ardından kullandığım, NGINX yapılandırma dosyası ise şu şekilde

server {
    listen                  443 ssl http2;
    listen                  [::]:443 ssl http2;
    server_name             git.mertcan.dev;
    root                    /var/www/git.mertcan.dev/public;

    # SSL
    ssl_certificate         /root/.acme.sh/mertcan.dev/fullchain.cer;
    ssl_certificate_key     /root/.acme.sh/mertcan.dev/mertcan.dev.key;
    ssl_trusted_certificate /root/.acme.sh/mertcan.dev/fullchain.cer;

    # reverse proxy
    location / {
        proxy_pass http://localhost:3000;
    }

}

Ardından NGINX yeniden başlattığınız anda kurulum ekranı karşınıza çıkacak, gerisi size kalmış durumda. Gitea uygulaması üzerinde yapacağınız değişiklikler için /var/lib/docker/volumes/gitea_gitea/_data/gitea/conf/ yolu içerisinde yer alan app.ini dosyasını değiştiriniz.

Yanlış yapılandırılan her docker konteyneri dışarıya yüklü miktarda log basar, disk alanı az olan sunucularda sistem yöneticileri güneşi hızlı bir şekilde görebilir ve servis kesintileri yaşayabilir.

Aşağıda yapacaklarımızdan hemen önce lütfen docker-compose dosyanız üzerinde gerekli olan ince ayarları yapınız, aksi taktirde yapacağınız bu işlemlerin log dosyalarının boyutunu düşürmede bir etkisi olmayacaktır.

logging:
      driver: "json-file"
      options:
        max-size: "1g"
        max-file: "10"

Bir müşteride mevcut logların boyutunu şu şekilde gördüm, burada anladığım kadarıyla 2 konteyner aktif olarak kullanılmış ve üzerinde ciddi anlamda işlem yapılmış ve log üretilmiş.

-rw-r----- 1 root root 40,2M 2020-08-20  /var/lib/docker/containers/cff872f1769dfed9c36d5f7e61627d2ff77973441325b07847fb4874ef1a0acf/cff872f1769dfed9c36d5f7e61627d2ff77973441325b07847fb4874ef1a0acf-json.log
-rw-r----- 1 root root 8,2M 2020-08-20  /var/lib/docker/containers/02a78f490f6b7ace252f3126689cf9200f488e94b909b9a2e5ee29613a1ee305/02a78f490f6b7ace252f3126689cf9200f488e94b909b9a2e5ee29613a1ee305-json.log
-rw-r----- 1 root root 3,3M 06-10 11:19 /var/lib/docker/containers/4cb9f353b394287dff456c1ce08d13c1a3206ad902e44eb5a5f3cd33e747320c/4cb9f353b394287dff456c1ce08d13c1a3206ad902e44eb5a5f3cd33e747320c-json.log
-rw-r----- 1 root root 578G 09-22 10:12 /var/lib/docker/containers/7e1bb748c785343f47511e08cb10aa676df09d4fc4abe1f371bc7b49a3d88b9d/7e1bb748c785343f47511e08cb10aa676df09d4fc4abe1f371bc7b49a3d88b9d-json.log

Bu loga ulaşmak için şu komutu kullandım

docker ps -aq | xargs -I'{}' docker inspect --format='{{.LogPath}}' '{}' | xargs ls -lh

Müşteri bana logların önemli olabilecek verileri uzak storageda tutabileceğini ve gerektiği kadarını silmemi (bence saçma, bir işine yaramaz bu log ama neyse)

cat /var/lib/docker/containers/*-json.log | bzip2 --best --compress --stdout > /mnt/nfs-storage-shared/2020-09-22.log.bz2

Ardından log dosyasını bölmem ve çoğunu kesmem gerektiği için apt install util-linux kurulumu yaptım(ilginç şekilde yüklü değildi), ardından fallocate ile dosyayı bölme işlemine geçiş yaptım ve aşağıdaki gibi büyük çoğunluğunu uçurdum.

fallocate --collapse-range --offset 0 --length 577GiB --verbose /var/lib/docker/containers/7e1bb748c785343f47511e08cb10aa676df09d4fc4abe1f371bc7b49a3d88b9d/7e1bb748c785343f47511e08cb10aa676df09d4fc4abe1f371bc7b49a3d88b9d-json.log

Böylelikle dosyada 1 GB‘lik kısmı bıraktım, ancak ben bunu yapıncaya kadar sistemde yapılan işlemler sebebiyle +4 GB kadar daha log birikmişti. Docker ile ilgilenen arkadaşa ilettim konuyu(ancak çözmemiş)

Otomatik log rotasyonu aktif edildiği taktirde bu makalede anlatılan çözümü yapmanıza gerek yok.