Son zamanlarda Vigilant uygulamasına sağlık kontrolleri gibi yeni bir özellik ekledim. Vigilant, bir web sitesinin tüm yönlerini izlemek için tasarlanmış bir açık kaynak izleme uygulamasıdır. Sağlık kontrolleri ile, kritik süreçlerin çalışıp çalışmadığını doğrulayabiliriz, örneğin bir Laravel zamanlayıcı veya Redis bağlantısı. Ayrıca bu boolen türündeki kontrollerin yanı sıra, temel sistem istatistiklerini (cpu, bellek ve disk alanı gibi) sergilememizi sağlayan metrikler de ekledim. Uygulamadaki günlük dosyalarının boyutunu ekleyerek, bu değerler yükseldiğinde bildirim alabiliriz!
Bu sağlık kontrolleri için ortak bir arayüzü tanımlamak üzere bir healthcheck-base paketi oluşturdum. Çerçeveye özgü paketler bunun üzerine inşa edilir ve sorunsuz bir şekilde entegre olurken, Vigilant olmadan da kullanılabilir hale gelir.
Daha sonra Laravel veya Statamic’e özgü kontroller ekleyen ayrı paketler oluşturdum. Bunlar, Vigilant olmadan çalışacak şekilde tasarlanmış, fakat yine de sorunsuz bir entegrasyona sahiptir.
Paket Geliştirme
Paket Geliştirme
Paket geliştirme için olağan yöntem, bir projenin mevcut bir dizinine composer deposu olarak eklemek ve composer’ın bir simlink oluşturmasına izin vermektir. Bu işlem hakkında bilgi burada bulunmaktadır ve geliştirme için iyi bir yöntemdir.
Statamic’in temel geliştiricilerinden biri olan Duncan McClean, bu simlinkleri manuel olarak oluşturmak için tether adında bir script oluşturdu. Ben de, her seferinde composer.json dosyasını manuel olarak düzenlemek zorunda kalmamak için, kendim de daha basit bir script yazdım. İşte script:
#!/bin/bash
# Link a local package in a Laravel project
# Usage: lpackage.sh Bu script, proje dizininden çalıştırıldığında, ön koşul olarak hedef paket projenin içinde önceden yüklenmişse, herhangi bir paketi bağlar. Bu script, kasıtlı olarak minimaldir ve yerel kurulumuma özeldir.
Bu yöntemin dezavantajı, temiz bir proje ile başlamadığınızdan, projedeki bir şeyin paketinizi etkileme riski olur. Küçük bir örnek; projenin servis sağlayıcısında Model::unguard( kullanmak, bir paket içinde atlamak kolaydır, ancak paketin başka bir projeye dahil edilmesi durumunda sorun çıkarır.
Yanlış anlamayın, bu yöntemler mükemmel bir şekilde geçerlidir fakat bazen, paketin kesinlikle çalıştığından emin olmak için temiz bir kuruluşa sahip olmak güzeldir.
Docker Ortamı Oluşturalım
Docker Ortamı Oluşturalım
Bu ortam bir temiz uygulama kurmalı ve paketimizi yüklemelidir. Tercihen, değişikliklerimiz hemen etkili olması için paketimize simlink yapmalıyız. Ek olarak, MySQL ve Redis gibi çeşitli hizmetleri kurmak için Docker Compose kullanacağım. Statamic durumunda her seferinde bir admin hesabı oluşturmak zorunda kalmamak için birkaç ayar da yapmam gerekir. Öncelikle Dockerfile ile başlayalım; aşırı yükü azaltmak için artisan serve kullanarak istekleri idare edeceğiz ve cron yerine schedule:work kullanacağız. Bu işlemlerin yürütülmesi için supervisor kullanacağız.
Peki, ne yapmamız gerekiyor?
- Temel bir görüntü seçin
- Gerekli bağımlılıkları ekleyin
- Composer’ı yükleyin ve yeni bir Laravel / Statamic projesi oluşturun
- Paketimizi yükleyin
- Gerekli hizmetleri çalıştırın
Temel görüntümüz ile başlayalım; PHP 8.5 içeren Debian tabanlı php:8.5-cli görüntüsünü kullanmayı tercih ettim. Dockerfile’ımızın başlangıcı şöyle görünüyor:
FROM php:8.5-cli WORKDIR /srv
Daha sonra supervisor ve PHP uzantıları gibi bağımlılıklarımızı kurmamız gerekiyor:
RUN apt-get update \
&& apt-get install -y --no-install-recommends git unzip libzip-dev supervisor \
&& docker-php-ext-install zip pcntl \
&& pecl install redis \
&& docker-php-ext-enable redis \
&& rm -rf /var/lib/apt/lists/*
Composer’ı kurabilir ve projeyi oluşturabiliriz:
COPY --from=composer:2 /usr/bin/composer /usr/bin/composer
RUN composer create-project --no-interaction --no-progress laravel/laravel app
// Veya Statamic için:
RUN composer create-project --no-interaction --no-progress statamic/statamic app
Artık bir projemiz kurulu olduğuna göre paketimizi kopyalayıp diğer yapılandırmaları yerine getirebiliriz:
COPY . /srv/package
WORKDIR /srv/app
RUN composer config minimum-stability dev \
&& composer config prefer-stable true \
&& composer config repositories.statamic-healthchecks path /srv/package \
&& composer require --no-interaction --no-progress govigilant/statamic-healthchecks:dev-main laravel/horizon \
&& php artisan key:generate \
&& php artisan horizon:install
Son olarak, supervisor yapılandırmamızı kopyalayıp başlatabiliriz:
RUN rm -rf /var/www/html \
&& mv /srv/app /var/www/html \
&& mkdir -p /var/log/supervisor
WORKDIR /var/www/html
COPY devenv/supervisord.conf /etc/supervisor/conf.d/healthchecks.conf
EXPOSE 8000
CMD ["supervisord", "-n"]
İşte final Dockerfile’ımız:
FROM php:8.5-cli
WORKDIR /srv
RUN apt-get update \
&& apt-get install -y --no-install-recommends git unzip libzip-dev supervisor \
&& docker-php-ext-install zip pcntl \
&& pecl install redis \
&& docker-php-ext-enable redis \
&& rm -rf /var/lib/apt/lists/*
COPY --from=composer:2 /usr/bin/composer /usr/bin/composer
RUN composer create-project --no-interaction --no-progress laravel/laravel app
COPY . /srv/package
WORKDIR /srv/app
RUN composer config minimum-stability dev \
&& composer config prefer-stable true \
&& composer config repositories.statamic-healthchecks path /srv/package \
&& composer require --no-interaction --no-progress govigilant/statamic-healthchecks:dev-main laravel/horizon \
&& php artisan key:generate \
&& php artisan horizon:install
RUN rm -rf /var/www/html \
&& mv /srv/app /var/www/html \
&& mkdir -p /var/log/supervisor
WORKDIR /var/www/html
COPY devenv/supervisord.conf /etc/supervisor/conf.d/healthchecks.conf
EXPOSE 8000
CMD ["supervisord", "-n"]
Statamic Kullanıcısı
Statamic Kullanıcısı
Statamic için kontrol paneline giriş yapmak üzere bir kullanıcıya ihtiyacımız var. Bunun için paket deposundaki users dizinini oluşturdum. Dockerfile’da bunu Statamic klasörüne kopyalıyorum:
COPY devenv/users/ /srv/app/users/
Supervisor yapılandırması şu şekilde, stdout’un spamlanmasını önlemek için günlükleri ayrı dosyalarda tutuyoruz:
[supervisord]
nodaemon=true
[program:php]
command=php artisan serve --host=0.0.0.0 --port=8000
directory=/var/www/html
autostart=true
autorestart=true
stdout_logfile=/var/log/supervisor/php.log
stderr_logfile=/var/log/supervisor/php.err.log
[program:horizon]
command=php artisan horizon
directory=/var/www/html
autostart=true
autorestart=true
stdout_logfile=/var/log/supervisor/horizon.log
stderr_logfile=/var/log/supervisor/horizon.err.log
[program:scheduler]
command=php artisan schedule:work
directory=/var/www/html
autostart=true
autorestart=true
stdout_logfile=/var/log/supervisor/scheduler.log
stderr_logfile=/var/log/supervisor/scheduler.err.log
Bunu hızlıca inceleyelim, şu hizmetleri başlatıyor:
- php artisan serve — host=0.0.0.0 — port=8000 — HTTP isteklerini işlemek için
- php artisan horizon — Paketteki Horizon kontrollerinin çalıştığını doğrulamak için
- php artisan schedule:work — Paketteki zamanlayıcı kontrolünün çalıştığını doğrulamak için
Bilmiyorsanız, supervisor bir programdır ve başka programları çalıştırmanızı sağlar. Bir şey çöktüğünde, supervisor onu tekrar başlatır. Basit yapılandırma ile hizmetleri çalışır durumda tutmak için yararlı bir araçtır.
Şimdi Dockerfile’ımıza bir compose dosyası oluşturabiliriz. Bu dosya, hizmetleri tanımlar ve temiz uygulamamız dahil olmak üzere ihtiyaç duyduğumuz hizmetleri bir araya getirir. Bu dosya ile, tüm yığını tek bir komutla başlatabiliriz ve her şey konteynerleştirildiği için her ana sistemde aynı performansı garanti edebiliriz.
Göz önünde bulundurmanızı istediğim bir nokta; uygulama konteyneri için bir görüntü yerine, Dockerfile’ımızı geçiyoruz. Paketi ve çevre dosyasını uygulama konteynerine bağlıyoruz. Bu env dosyası, veritabanı, redis ve paket yapılandırması için bazı temel ayarları içerir.
services:
app:
build:
context: ..
dockerfile: devenv/Dockerfile
ports:
- "8000:8000"
volumes:
- ../:/srv/package
- ./app.env:/var/www/html/.env
depends_on:
- mysql
- redis
mysql:
image: mysql:8.4
environment:
MYSQL_ROOT_PASSWORD: secret
MYSQL_DATABASE: laravel
MYSQL_USER: laravel
MYSQL_PASSWORD: secret
volumes:
- mysql-data:/var/lib/mysql
redis:
image: redis:7-alpine
command: ["redis-server", "/usr/local/etc/redis/redis.conf"]
volumes:
- ./redis.conf:/usr/local/etc/redis/redis.conf
volumes:
mysql-data:
Ve işte bu kadar, artık paketimizi geliştirmek ve test etmek için özel ve temiz bir ortama sahibiz.
Ekstralar
Ekstralar
Şu anda, bunu geliştirme için kullanıyorum ve bu sunucuları (internetten erişilemeyen) sağlık kontrollerinin sunucu tarafını test etmek için kullanıyorum. Her birini güncelleyen küçük bir script yazdım ve değişiklikleri çekip konteynerleri yeniden inşa ediyorum.
Ayrıca, bu Docker görüntüsünü bir pipeline’da çalıştırmak, örneğin bir entegrasyon testi yapmak için güzel bir ekleme olabilir.
Statamic 6’ya Yükseltme
Statamic 6’ya Yükseltme
Statamic 6 piyasaya sürüldüğünde, statamic-healthchecks eklentisini uyumlu hale getirmek için güncellemeler yapmak zorunda kaldım. Bu, statamic/cms kısıtlamasını ^5.0 dan ^6.0‘e güncellemeyi ve CI matrisini güncellemeyi içeriyordu. Ayrıca Vue 2 ön yüz kaynaklarını Vue 3’e taşımak durumunda kaldım. Kod değişiklikleri tamamlandıktan sonra, her şeyin uçtan uca çalıştığını doğrulamak için Docker ortamının ne kadar işe yaradığını gördüm.
Özel bir ortam olmadan, mevcut bir Statamic projesini manuel olarak güncellemek, orada paketi kurup test etmek zorunda kalırdım. Docker yapılandırmamla, yalnızca görüntüyü yeniden oluşturmak zorundaydım. Oluşturma süreci, composer create-project statamic/statamic işlemini her defasında sıfırdan çalıştırır, bu yüzden bir yeniden yapılandırma, güncellenmiş paketi yüklemiş temiz bir Statamic 6 kurulumunu bana verdi.
Konteyner, temiz bir şekilde başlatıldı ve sağlık kontrolü uç noktası, beklenen yanıtı döndürdü, bu da özel statamic_stache kontrolünü içeriyordu. Güncellemeyi, mevcut projeye dokunmadan temiz bir Statamic 6 kurulumunda doğrulamış oldum.
Tüm paketler böyle bir ortam ile mi gönderilmeli?
Tüm paketler böyle bir ortam ile mi gönderilmeli?
Kesinlikle hayır. Bu, pakete ve hedeflere bağlı. Buradaki amaç, paketi test etmek için temiz bir kurulum elde etmek ve bir test ortamı oluşturmak. Geleneksel simlinkleme yöntemi, çoğu durumda hâlâ tercih edilen bir yöntemdir. Bu nedenle, çoğu pakette simlinkleme yeterlidir. Ancak, temiz, çoğaltılabilir bir yapılandırmaya ihtiyaç duyulduğunda, Docker’ın üstesinden gelmesi zor.
Bu yazı, https://govigilant.io adresindeki 6 Nisan 2026 tarihinde yayımlanmıştır.
Kaynak: Orijinal Makale
