Dijital d\u00fcnyada ki\u015fisel veya kurumsal bir varl\u0131k olu\u015fturman\u0131n en etkili yollar\u0131ndan biri blog yazmakt\u0131r. Ancak i\u00e7erik \u00fcretmek kadar, bu i\u00e7eri\u011fi h\u0131zl\u0131, g\u00fcvenli ve verimli bir \u015fekilde yay\u0131nlamak da b\u00fcy\u00fck bir zorluk te\u015fkil edebilir. Manuel yay\u0131nlama s\u00fcre\u00e7leri, hem zaman al\u0131c\u0131 hem de hata yapmaya a\u00e7\u0131k oldu\u011fundan, otomasyon ihtiyac\u0131 ka\u00e7\u0131n\u0131lmaz hale gelir. \u0130\u015fte bu noktada, kendi \u00f6zel i\u00e7erik yay\u0131nlama sunucumu (My Custom Publisher – MCP) geli\u015ftirme ser\u00fcvenim ba\u015flad\u0131. Bu makalede, bir Git deposundaki Markdown dosyalar\u0131n\u0131 al\u0131p, statik bir site jenerat\u00f6r\u00fc arac\u0131l\u0131\u011f\u0131yla HTML’e d\u00f6n\u00fc\u015ft\u00fcrerek otomatik olarak bir web sunucusuna da\u011f\u0131tan bir sistemi nas\u0131l kurdu\u011fumu, bu s\u00fcre\u00e7te kar\u015f\u0131la\u015ft\u0131\u011f\u0131m zorluklar\u0131 ve onlarla nas\u0131l ba\u015fa \u00e7\u0131kt\u0131\u011f\u0131m\u0131 ad\u0131m ad\u0131m anlataca\u011f\u0131m. Amac\u0131m, hem kendi yay\u0131nlama s\u00fcre\u00e7lerimi optimize etmek hem de benzer bir ihtiyac\u0131 olan geli\u015ftiricilere yol g\u00f6stermekti.<\/p>\n
G\u00fcn\u00fcm\u00fczde bir\u00e7ok pop\u00fcler blog platformu (WordPress, Medium, Blogger vb.) mevcut. Bunlar, h\u0131zl\u0131 ba\u015flang\u0131\u00e7 yapma ve teknik bilgi gerektirmeden i\u00e7erik yay\u0131nlama konusunda b\u00fcy\u00fck kolayl\u0131klar sunar. Ancak, bu platformlar\u0131n getirdi\u011fi baz\u0131 k\u0131s\u0131tlamalar, \u00f6zellikle benim gibi tam kontrol ve esneklik arayan geli\u015ftiriciler i\u00e7in yetersiz kalabilir. Mevcut platformlar genellikle belirli bir tasar\u0131ma, eklenti ekleme s\u0131n\u0131rlamalar\u0131na ve veri sahipli\u011fi konusunda soru i\u015faretlerine sahiptir. Kendi i\u00e7erik stratejimi, performans beklentilerimi ve g\u00fcvenlik standartlar\u0131m\u0131 tam olarak kar\u015f\u0131layacak bir \u00e7\u00f6z\u00fcme ihtiyac\u0131m vard\u0131.<\/p>\n
Statik site jenerat\u00f6rleri (Jekyll, Hugo, Gatsby gibi), bu k\u0131s\u0131tlamalar\u0131n \u00e7o\u011funu ortadan kald\u0131r\u0131yor. Markdown gibi basit metin formatlar\u0131nda i\u00e7erik yazma imkan\u0131 sunarken, bu i\u00e7erikleri h\u0131zl\u0131 ve g\u00fcvenli statik HTML dosyalar\u0131na d\u00f6n\u00fc\u015ft\u00fcr\u00fcyorlar. Bu sayede, sunucu taraf\u0131nda veritaban\u0131 veya karma\u015f\u0131k bir uygulama katman\u0131 olmad\u0131\u011f\u0131 i\u00e7in g\u00fcvenlik a\u00e7\u0131klar\u0131 azal\u0131yor ve sayfa y\u00fckleme h\u0131zlar\u0131 inan\u0131lmaz derecede art\u0131yor. Ancak statik site jenerat\u00f6rlerini kullanman\u0131n da kendine g\u00f6re bir zahmeti var: Her i\u00e7erik g\u00fcncellemesinde, jenerat\u00f6r\u00fc \u00e7al\u0131\u015ft\u0131rman\u0131z, dosyalar\u0131 derlemeniz ve ard\u0131ndan bunlar\u0131 bir web sunucusuna (genellikle SSH veya FTP arac\u0131l\u0131\u011f\u0131yla) manuel olarak y\u00fcklemeniz gerekiyor. Birka\u00e7 blog yaz\u0131s\u0131 i\u00e7in bu kabul edilebilir olsa da, d\u00fczenli olarak i\u00e7erik yay\u0131nlad\u0131\u011f\u0131n\u0131zda bu tekrarlayan ve zaman al\u0131c\u0131 bir g\u00f6reve d\u00f6n\u00fc\u015f\u00fcyor. \u0130\u015fte tam da bu noktada, bir otomasyon \u00e7\u00f6z\u00fcm\u00fc geli\u015ftirmek ka\u00e7\u0131n\u0131lmaz hale geldi. Amac\u0131m, sadece bir git push<\/span> komutuyla, yeni blog yaz\u0131lar\u0131m\u0131n veya g\u00fcncellemelerimin saniyeler i\u00e7inde yay\u0131nda olmas\u0131n\u0131 sa\u011flamakt\u0131. Bu vizyon, beni kendi \u00f6zel yay\u0131nlama sunucumu, yani MCP sunucumu in\u015fa etmeye itti.<\/p>\n Bu otomasyon, sadece zaman tasarrufu sa\u011flamakla kalmayacak, ayn\u0131 zamanda insan hatas\u0131 riskini de minimize edecekti. Manuel dosya transferlerinde yanl\u0131\u015f dizine kopyalama, eski dosyalar\u0131 unutma veya izin hatalar\u0131 gibi sorunlar s\u0131k\u00e7a ya\u015fanabilir. Otomatik bir sistemle, bu t\u00fcr hatalar\u0131n \u00f6n\u00fcne ge\u00e7mek ve yay\u0131nlama s\u00fcrecini standartla\u015ft\u0131rmak m\u00fcmk\u00fcnd\u00fc. Ayr\u0131ca, kendi sunucumu kurmak, hangi programlama dillerini ve ara\u00e7lar\u0131n\u0131 kullanaca\u011f\u0131m konusunda bana tam bir \u00f6zg\u00fcrl\u00fck tan\u0131yordu. B\u00f6ylece, en iyi bildi\u011fim ve en verimli \u00e7al\u0131\u015ft\u0131\u011f\u0131m teknolojileri kullanarak, tamamen kendi ihtiya\u00e7lar\u0131ma g\u00f6re \u015fekillendirilmi\u015f bir \u00e7\u00f6z\u00fcm ortaya \u00e7\u0131karabilirdim. Bu, sadece bir blog yay\u0131nlama arac\u0131 de\u011fil, ayn\u0131 zamanda bir \u00f6\u011frenme ve geli\u015ftirme projesi olacakt\u0131.<\/p>\n MCP, bu makale \u00f6zelinde geli\u015ftirdi\u011fim “My Custom Publisher” (Kendi \u00d6zel Yay\u0131nlay\u0131c\u0131m) sunucusunun k\u0131saltmas\u0131d\u0131r. Temel amac\u0131, bir Git deposundaki (\u00f6rne\u011fin GitHub veya GitLab) de\u011fi\u015fiklikleri otomatik olarak alg\u0131lamak, bu de\u011fi\u015fiklikleri kullanarak statik bir web sitesi olu\u015fturmak ve son olarak bu siteyi bir web sunucusuna da\u011f\u0131tmakt\u0131r. Bu sistem, bir nevi ki\u015fisel ve hafif bir s\u00fcrekli entegrasyon\/s\u00fcrekli da\u011f\u0131t\u0131m (CI\/CD) hatt\u0131 g\u00f6revi g\u00f6r\u00fcr. Projenin kalbinde, Git entegrasyonu, bir webhook dinleyicisi ve statik site jenerat\u00f6r\u00fc ile sorunsuz bir etkile\u015fim yatar.<\/p>\n MCP sunucusunun mimarisini tasarlarken, esneklik, g\u00fcvenilirlik ve d\u00fc\u015f\u00fck bak\u0131m maliyeti \u00f6nceliklerim aras\u0131ndayd\u0131. Bu hedefler do\u011frultusunda, a\u015fa\u011f\u0131daki ana bile\u015fenlerden olu\u015fan bir yap\u0131 olu\u015fturmaya karar verdim:<\/p>\n Bu bile\u015fenler aras\u0131ndaki ileti\u015fim ak\u0131\u015f\u0131 \u015fu \u015fekilde i\u015fler:<\/p>\n Bu mimari, manuel m\u00fcdahaleyi minimuma indirerek, i\u00e7erik yay\u0131nlama s\u00fcrecini son derece verimli ve hatas\u0131z hale getirmeyi ama\u00e7lar. Node.js’i tercih etmemin nedeni, asenkron yap\u0131s\u0131yla e\u015f zamanl\u0131 i\u015flemleri kolayca y\u00f6netebilmesi ve geni\u015f bir paket ekosistemine sahip olmas\u0131yd\u0131. Bu sayede, webhook i\u015fleme, komut \u00e7al\u0131\u015ft\u0131rma ve hata y\u00f6netimi gibi g\u00f6revleri etkili bir \u015fekilde yerine getirebildim. Ayr\u0131ca, bu yakla\u015f\u0131m, sistemin \u00f6l\u00e7eklenebilirli\u011fini de art\u0131r\u0131r; gelecekte daha fazla blog veya statik site eklemek istedi\u011fimde, mevcut altyap\u0131y\u0131 kolayca geni\u015fletebilirim.<\/p>\n MCP sunucusunu hayata ge\u00e7irmek i\u00e7in ilk ad\u0131m, uygun bir sunucu ortam\u0131 haz\u0131rlamakt\u0131. Genellikle sanal bir \u00f6zel sunucu (VPS) veya kendi yerel makinenizde bir Linux da\u011f\u0131t\u0131m\u0131 (Ubuntu, Debian) bu i\u015f i\u00e7in yeterli olacakt\u0131r. Benim tercihim, maliyet etkinli\u011fi ve esnekli\u011fi nedeniyle bir bulut tabanl\u0131 VPS oldu. Kurulum s\u00fcreci a\u015fa\u011f\u0131daki ad\u0131mlar\u0131 i\u00e7eriyordu:<\/p>\n Bir Node.js projesi ba\u015flatt\u0131m ve express<\/span> ile body-parser<\/span> paketlerini kurdum. Bu paketler, gelen HTTP isteklerini y\u00f6netmek ve JSON g\u00f6vdelerini ayr\u0131\u015ft\u0131rmak i\u00e7in kullan\u0131lacakt\u0131.<\/p>\n Yukar\u0131daki kod, basit bir webhook dinleyicisi olu\u015fturur. \/webhook<\/span> adresine POST iste\u011fi geldi\u011finde, git pull<\/span> ile depoyu g\u00fcnceller ve hugo –minify -d ${publishPath}<\/span> komutuyla Hugo’yu \u00e7al\u0131\u015ft\u0131rarak statik dosyalar\u0131 do\u011frudan Nginx’in servis etti\u011fi \/var\/www\/blog<\/span> dizinine derler. Bu, rsync<\/span> kullanmaktan daha do\u011frudan bir yakla\u015f\u0131md\u0131r, ancak Hugo’nun \u00e7\u0131k\u0131\u015f dizinini do\u011frudan hedef olarak ayarlaman\u0131z\u0131 gerektirir.<\/p>\n<\/li>\n Blog kaynak kodumun bulundu\u011fu Git deposunu sunucuya klonlad\u0131m: git clone https:\/\/github.com\/myuser\/my-blog-repo.git \/home\/user\/my-blog-repo<\/span>. Daha sonra, GitHub veya GitLab aray\u00fcz\u00fcnden, projenin “Settings” (Ayarlar) b\u00f6l\u00fcm\u00fcndeki “Webhooks” k\u0131sm\u0131na giderek yeni bir webhook ekledim. Payload URL olarak http:\/\/your_server_ip:3000\/webhook<\/span> adresini girdim ve tetikleyici olarak sadece “Push events” (G\u00f6nderme olaylar\u0131) se\u00e7ene\u011fini i\u015faretledim. G\u00fcvenlik i\u00e7in bir “Secret” (Gizli anahtar) belirlemeyi de unutmad\u0131m, bu konuya daha sonra de\u011finece\u011fim.<\/p>\n<\/li>\n MCP sunucusunun s\u00fcrekli \u00e7al\u0131\u015f\u0131r durumda kalmas\u0131 i\u00e7in pm2<\/span> gibi bir s\u00fcre\u00e7 y\u00f6neticisi kulland\u0131m: npm install -g pm2<\/span> ve ard\u0131ndan pm2 start server.js<\/span>. Bu, sunucunun \u00e7\u00f6kmesi durumunda otomatik olarak yeniden ba\u015flamas\u0131n\u0131 da sa\u011flar.<\/p>\n<\/li>\n<\/ol>\n Bu ad\u0131mlarla, temel bir otomasyon ak\u0131\u015f\u0131 kurulmu\u015f oldu. Art\u0131k, Git deposuna yeni bir blog yaz\u0131s\u0131 g\u00f6nderdi\u011fimde, webhook tetiklenecek ve sunucum otomatik olarak blogumu g\u00fcncelleyecekti. Ancak, her projede oldu\u011fu gibi, bu ilk kurulum s\u00fcrecinde de \u00e7e\u015fitli zorluklarla kar\u015f\u0131la\u015ft\u0131m ve hata ay\u0131klama s\u00fcre\u00e7leri ka\u00e7\u0131n\u0131lmaz oldu.<\/p>\n Her geli\u015ftirme projesi gibi, MCP sunucusu kurulumu da beklenmedik sorunlarla doluydu. \u0130lk ba\u015far\u0131l\u0131 git push<\/span> denememde blogumun otomatik olarak g\u00fcncellenmemesi, beni bir hata ay\u0131klama maratonuna s\u00fcr\u00fckledi. \u0130\u015fte kar\u015f\u0131la\u015ft\u0131\u011f\u0131m ba\u015fl\u0131ca zorluklar ve bunlar\u0131 a\u015fmak i\u00e7in kulland\u0131\u011f\u0131m stratejiler:<\/p>\n \u0130lk ba\u015fta, Git platformundan gelen webhook’lar\u0131n sunucuma ula\u015f\u0131p ula\u015fmad\u0131\u011f\u0131ndan emin olamad\u0131m. Bazen, webhook’lar hi\u00e7 tetiklenmiyor ya da sunucuya ula\u015ft\u0131\u011f\u0131nda do\u011fru \u015fekilde i\u015flenmiyordu. Bu sorunu \u00e7\u00f6zmek i\u00e7in a\u015fa\u011f\u0131daki ad\u0131mlar\u0131 izledim:<\/p>\n En s\u0131k kar\u015f\u0131la\u015f\u0131lan sorunlardan biri, sunucunun Git deposunu \u00e7ekmek ve hedef dizine dosya yazmak i\u00e7in yeterli yetkiye sahip olmamas\u0131yd\u0131. exec<\/span> komutlar\u0131 genellikle sunucuyu \u00e7al\u0131\u015ft\u0131ran kullan\u0131c\u0131 alt\u0131nda \u00e7al\u0131\u015f\u0131r. E\u011fer MCP sunucusunu root<\/span> olmayan bir kullan\u0131c\u0131yla \u00e7al\u0131\u015ft\u0131r\u0131yorsan\u0131z (ki bu en iyi g\u00fcvenlik uygulamas\u0131d\u0131r), o kullan\u0131c\u0131n\u0131n Git deposu dizinine okuma\/yazma ve hedef yay\u0131nlama dizinine yazma izinleri olmal\u0131d\u0131r.<\/p>\n Hugo’nun exec<\/span> komutu arac\u0131l\u0131\u011f\u0131yla \u00e7al\u0131\u015ft\u0131r\u0131lmas\u0131 bazen beklenen \u015fekilde sonu\u00e7 vermiyordu. En yayg\u0131n sorun, hugo<\/span> komutunun sistemin PATH<\/span> de\u011fi\u015fkeninde bulunamamas\u0131yd\u0131. Bu durumda exec<\/span> komutu command not found<\/span> (komut bulunamad\u0131) hatas\u0131 d\u00f6nd\u00fcr\u00fcr.<\/p>\n B\u00fcy\u00fck blog siteleri i\u00e7in Hugo’nun derleme s\u00fcreci birka\u00e7 saniye s\u00fcrebilir. E\u011fer webhook iste\u011fi bu s\u00fcreden daha uzun s\u00fcrerse, Git platformu bir zaman a\u015f\u0131m\u0131 hatas\u0131 bildirebilir ve iste\u011fi ba\u015far\u0131s\u0131z olarak i\u015faretleyebilir. Bu, asl\u0131nda yay\u0131nlama ba\u015far\u0131l\u0131 olsa bile, Git platformunun aray\u00fcz\u00fcnde hatal\u0131 bir durum g\u00f6rmenize neden olurdu.<\/p>\n Vaka Analizi: “Bir Gece Yay\u0131nlanmayan Blog Postu”<\/strong><\/p>\n Bir keresinde, yeni bir blog yaz\u0131s\u0131 yay\u0131mlamak i\u00e7in git push<\/span> yapt\u0131m, ancak sabah uyand\u0131\u011f\u0131mda blogumda g\u00f6r\u00fcnmedi\u011fini fark ettim. GitHub’\u0131n webhook ge\u00e7mi\u015fine bakt\u0131\u011f\u0131mda, iste\u011fin “ba\u015far\u0131s\u0131z” olarak i\u015faretlendi\u011fini g\u00f6rd\u00fcm. Sunucu loglar\u0131n\u0131 kontrol etti\u011fimde, git pull<\/span> komutunun “Permission denied (publickey)” (\u0130zin reddedildi (genel anahtar)) hatas\u0131 verdi\u011fini fark ettim. Sorun, sunucuyu \u00e7al\u0131\u015ft\u0131ran kullan\u0131c\u0131n\u0131n SSH anahtar\u0131n\u0131n GitHub’da da\u011f\u0131t\u0131m anahtar\u0131 olarak do\u011fru \u015fekilde eklenmemi\u015f olmas\u0131yd\u0131. Anahtar\u0131 ekledikten ve do\u011fru izinleri ayarlad\u0131ktan sonra sorun \u00e7\u00f6z\u00fcld\u00fc. Bu olay, loglama ve hata \u00e7\u0131kt\u0131lar\u0131n\u0131 dikkatle incelemenin ne kadar \u00f6nemli oldu\u011funu bir kez daha g\u00f6sterdi.<\/p>\n Bir i\u00e7erik yay\u0131nlama sunucusu kurarken, sadece i\u015flevsellik de\u011fil, ayn\u0131 zamanda performans ve g\u00fcvenlik de kritik \u00f6neme sahiptir. Blogumun h\u0131zl\u0131 y\u00fcklenmesini sa\u011flamak ve olas\u0131 sald\u0131r\u0131lara kar\u015f\u0131 korumak i\u00e7in bir dizi optimizasyon ve g\u00fcvenlik \u00f6nlemi ald\u0131m.<\/p>\n E\u011fer blogunuz k\u00fcresel bir kitleye hitap ediyorsa, bir CDN kullanmak performans\u0131 b\u00fcy\u00fck \u00f6l\u00e7\u00fcde art\u0131r\u0131r. CDN’ler, i\u00e7eri\u011finizi co\u011frafi olarak da\u011f\u0131t\u0131lm\u0131\u015f sunucularda \u00f6nbelle\u011fe alarak, kullan\u0131c\u0131lara en yak\u0131n sunucudan servis edilmesini sa\u011flar. Cloudflare gibi \u00fccretsiz veya uygun fiyatl\u0131 CDN hizmetleri bu i\u015f i\u00e7in idealdir. Bu, \u00f6zellikle resimler ve di\u011fer b\u00fcy\u00fck statik varl\u0131klar i\u00e7in faydal\u0131d\u0131r.<\/p>\n<\/li>\n<\/ol>\n Daha \u00f6nce de bahsetti\u011fim gibi, webhook isteklerinin ge\u00e7erlili\u011fini do\u011frulamak i\u00e7in bir gizli anahtar kullanmak zorunludur. Bu, sadece yetkili Git deposundan gelen isteklerin i\u015flenmesini sa\u011flar ve sunucunuzun rastgele POST istekleriyle k\u00f6t\u00fcye kullan\u0131lmas\u0131n\u0131 engeller.<\/p>\n<\/li>\n E\u011fer Git platformunuzun webhook isteklerini g\u00f6nderdi\u011fi IP adres aral\u0131klar\u0131 biliniyorsa (GitHub ve GitLab bu bilgiyi sa\u011flar), sunucunuzun g\u00fcvenlik duvar\u0131n\u0131 (UFW veya firewalld<\/span>) sadece bu IP adreslerinden gelen isteklere izin verecek \u015fekilde yap\u0131land\u0131rabilirsiniz. Bu, ek bir g\u00fcvenlik katman\u0131 sa\u011flar.<\/p>\n<\/li>\n Sunucuda gereksiz t\u00fcm portlar\u0131 kapatt\u0131m ve sadece SSH (22), HTTP (80) ve HTTPS (443) portlar\u0131na izin verdim. MCP sunucumun \u00e7al\u0131\u015ft\u0131\u011f\u0131 3000 numaral\u0131 portu ise sadece yerel a\u011fdan veya belirli IP’lerden eri\u015filebilir hale getirdim. sudo ufw allow 22\/tcp<\/span>, sudo ufw allow 80\/tcp<\/span>, sudo ufw allow 443\/tcp<\/span> gibi komutlarla.<\/p>\n<\/li>\n MCP sunucusu uygulamas\u0131n\u0131, m\u00fcmk\u00fcn olan en d\u00fc\u015f\u00fck yetkilere sahip bir kullan\u0131c\u0131 alt\u0131nda \u00e7al\u0131\u015ft\u0131rd\u0131m. root<\/span> kullan\u0131c\u0131s\u0131 veya sudo<\/span> yetkileriyle \u00e7al\u0131\u015ft\u0131rmaktan ka\u00e7\u0131nd\u0131m. Bu, olas\u0131 bir g\u00fcvenlik a\u00e7\u0131\u011f\u0131 durumunda sistem \u00fczerindeki zarar\u0131 s\u0131n\u0131rlar.<\/p>\n<\/li>\n Sunucuma SSH ile ba\u011flan\u0131rken parola yerine anahtar tabanl\u0131 kimlik do\u011frulama kulland\u0131m. Bu, parolan\u0131n tahmin edilmesi veya kaba kuvvet sald\u0131r\u0131lar\u0131na kar\u015f\u0131 \u00e7ok daha g\u00fcvenlidir.<\/p>\n<\/li>\n Blogumun ve MCP sunucumun g\u00fcvenli\u011fini art\u0131rmak i\u00e7in t\u00fcm trafi\u011fi HTTPS \u00fczerinden \u015fifreledim. Let’s Encrypt ve Certbot, \u00fccretsiz SSL\/TLS sertifikalar\u0131 almak ve bunlar\u0131 otomatik olarak yenilemek i\u00e7in harika ara\u00e7lard\u0131r. Bu, hem veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc sa\u011flar hem de SEO a\u00e7\u0131s\u0131ndan \u00f6nemlidir.<\/p>\n<\/li>\n Sunucu loglar\u0131n\u0131 d\u00fczenli olarak izlemek ve anormallikleri tespit etmek i\u00e7in log y\u00f6netim ara\u00e7lar\u0131 kulland\u0131m. Ayr\u0131ca, MCP sunucusunun kendi loglar\u0131n\u0131 da detayl\u0131 tutarak, herhangi bir yay\u0131nlama hatas\u0131 durumunda h\u0131zl\u0131ca m\u00fcdahale edebildim.<\/p>\n<\/li>\n<\/ol>\n Bu performans ve g\u00fcvenlik \u00f6nlemleri, MCP sunucumu sadece i\u015flevsel de\u011fil, ayn\u0131 zamanda sa\u011flam ve g\u00fcvenilir bir i\u00e7erik yay\u0131nlama platformu haline getirdi. Her bir ad\u0131m, hem kullan\u0131c\u0131 deneyimini iyile\u015ftirmeye hem de potansiyel riskleri minimize etmeye y\u00f6nelikti.<\/p>\n MCP sunucusunun temel i\u015flevselli\u011fini kurduktan ve performans\/g\u00fcvenlik \u00f6nlemlerini ald\u0131ktan sonra, sistemi daha da g\u00fc\u00e7lendirmek ve bir ad\u0131m \u00f6teye ta\u015f\u0131mak i\u00e7in ileri d\u00fczey otomasyon ve s\u00fcrekli da\u011f\u0131t\u0131m (CI\/CD) entegrasyonlar\u0131na y\u00f6neldim. Bu, sadece bir git push<\/span> ile blogu yay\u0131nlaman\u0131n \u00f6tesine ge\u00e7erek, daha karma\u015f\u0131k i\u015f ak\u0131\u015flar\u0131n\u0131 ve daha g\u00fcvenilir da\u011f\u0131t\u0131m s\u00fcre\u00e7lerini m\u00fcmk\u00fcn k\u0131ld\u0131.<\/p>\n \u00dcretim ortam\u0131na do\u011frudan yay\u0131nlama yapmak riskli olabilir. Bu nedenle, geli\u015ftirme, test ve \u00fcretim olmak \u00fczere farkl\u0131 ortamlar tan\u0131mlad\u0131m. \u00d6rne\u011fin, develop<\/span> dal\u0131na yap\u0131lan push’lar bir test sunucusuna, main<\/span> dal\u0131na yap\u0131lan push’lar ise canl\u0131 \u00fcretim sunucusuna yay\u0131nlanacak \u015fekilde MCP sunucumu yap\u0131land\u0131rd\u0131m. Bu, yeni \u00f6zelliklerin veya blog yaz\u0131lar\u0131n\u0131n canl\u0131ya \u00e7\u0131kmadan \u00f6nce test edilmesine olanak tan\u0131r.<\/p>\n MCP sunucusunu ve t\u00fcm ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131 bir Docker konteynerine ta\u015f\u0131mak, projenin ta\u015f\u0131nabilirli\u011fini, izole edilmesini ve da\u011f\u0131t\u0131m\u0131n\u0131 b\u00fcy\u00fck \u00f6l\u00e7\u00fcde kolayla\u015ft\u0131rd\u0131. Docker kullanarak, sunucumun farkl\u0131 ortamlarda (yerel geli\u015ftirme, test sunucusu, \u00fcretim sunucusu) tutarl\u0131 bir \u015fekilde \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flayabildim. Ayr\u0131ca, ba\u011f\u0131ml\u0131l\u0131k \u00e7ak\u0131\u015fmalar\u0131n\u0131 \u00f6nledi ve kurulum s\u00fcrecini basitle\u015ftirdi.<\/p>\n Bu Dockerfile ile, docker build -t mcp-server .<\/span> komutuyla bir Docker imaj\u0131 olu\u015fturabilir ve docker run -p 3000:3000 -e WEBHOOK_SECRET=your_secret mcp-server<\/span> komutuyla \u00e7al\u0131\u015ft\u0131rabilirim. Bu yakla\u015f\u0131m, sunucu ortam\u0131n\u0131 haz\u0131rlama karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 ortadan kald\u0131r\u0131r ve da\u011f\u0131t\u0131m s\u00fcrecini standartla\u015ft\u0131r\u0131r.<\/p>\n Daha sofistike i\u015f ak\u0131\u015flar\u0131 olu\u015fturmak i\u00e7in, webhook payload’undaki bilgilere dayanarak farkl\u0131 eylemleri tetikleyebilirim. \u00d6rne\u011fin:<\/p>\n Bu ileri d\u00fczey otomasyon ve CI\/CD entegrasyonlar\u0131, MCP sunucumu sadece basit bir yay\u0131nlama arac\u0131ndan, tam te\u015fekk\u00fcll\u00fc, g\u00fcvenilir ve esnek bir i\u00e7erik da\u011f\u0131t\u0131m sistemine d\u00f6n\u00fc\u015ft\u00fcrd\u00fc. Bu sayede, i\u00e7erik \u00fcretimine daha fazla odaklanabilir ve teknik detaylarla daha az u\u011fra\u015fabilirim.<\/p>\n Kendi \u00f6zel i\u00e7erik yay\u0131nlama sunucumu (MCP) in\u015fa etme ser\u00fcvenim, sadece teknik bir proje olman\u0131n \u00f6tesinde, bana paha bi\u00e7ilmez deneyimler kazand\u0131rd\u0131. Bu s\u00fcre\u00e7te, Node.js ile web sunucusu geli\u015ftirme, Git ile otomasyon entegrasyonu, Linux sunucu y\u00f6netimi, g\u00fcvenlik pratikleri ve hata ay\u0131klama stratejileri gibi bir\u00e7ok alanda bilgi ve becerilerimi derinle\u015ftirme f\u0131rsat\u0131 buldum. En \u00f6nemlisi, i\u00e7erik yay\u0131nlama s\u00fcrecim \u00fczerinde tam kontrol sa\u011flad\u0131m ve manuel i\u015f y\u00fck\u00fcn\u00fc s\u0131f\u0131ra indirerek verimlili\u011fimi art\u0131rd\u0131m.<\/p>\n MCP sunucusu sayesinde, art\u0131k yeni bir blog yaz\u0131s\u0131n\u0131 yazd\u0131ktan veya mevcut bir yaz\u0131y\u0131 g\u00fcncelledikten sonra tek yapmam gereken, de\u011fi\u015fiklikleri Git depoma g\u00f6ndermek. Geri kalan t\u00fcm ad\u0131mlar \u2013 depoyu \u00e7ekmek, statik siteyi derlemek ve web sunucusuna da\u011f\u0131tmak \u2013 tam otomatik olarak ger\u00e7ekle\u015fiyor. Bu otomasyon, bana yarat\u0131c\u0131 s\u00fcre\u00e7lere daha fazla odaklanma \u00f6zg\u00fcrl\u00fc\u011f\u00fc tan\u0131rken, ayn\u0131 zamanda blogumun her zaman g\u00fcncel ve hatas\u0131z kalmas\u0131n\u0131 sa\u011fl\u0131yor. Kendi altyap\u0131n\u0131z\u0131 kurman\u0131n getirdi\u011fi \u00f6\u011frenme e\u011frisi zorlay\u0131c\u0131 olsa da, elde edilen \u00f6zg\u00fcrl\u00fck, esneklik ve verimlilik bu \u00e7abaya kesinlikle de\u011fiyor.<\/p>\n Gelecekteki geli\u015ftirmeler aras\u0131nda, MCP sunucusuna bir y\u00f6netim paneli ekleyerek yay\u0131nlama ge\u00e7mi\u015fini g\u00f6rselle\u015ftirmek, farkl\u0131 bloglar veya projeler i\u00e7in \u00e7oklu depo deste\u011fi sunmak ve belki de i\u00e7erik y\u00f6netimini daha da kolayla\u015ft\u0131rmak i\u00e7in basit bir web tabanl\u0131 edit\u00f6r entegrasyonu yer al\u0131yor. Bu proje, kendi ihtiya\u00e7lar\u0131n\u0131za \u00f6zel \u00e7\u00f6z\u00fcmler geli\u015ftirmenin ve teknolojiyi kendi lehinize kullanman\u0131n g\u00fcc\u00fcn\u00fc bir kez daha g\u00f6sterdi.<\/p>\n #Teknoloji #WebGeli\u015ftirme #Otomasyon #CI\/CD #BlogYay\u0131nlama #DevOps<\/p>\n","protected":false},"excerpt":{"rendered":"Dijital d\u00fcnyada ki\u015fisel veya kurumsal bir varl\u0131k olu\u015fturman\u0131n en etkili yollar\u0131ndan biri blog yazmakt\u0131r.","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1],"tags":[],"class_list":{"0":"post-43758","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-genel","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\nMCP Sunucusu Nedir ve Temel Mimari Tasar\u0131m\u0131 Nas\u0131l Yap\u0131ld\u0131?<\/h3>\n
\n
\n
Ad\u0131m Ad\u0131m Kurulum ve \u0130lk Geli\u015ftirme S\u00fcreci<\/h3>\n
\n
\n
\n \/\/ server.js\n const express = require('express');\n const bodyParser = require('body-parser');\n const { exec } = require('child_process'); \/\/ Harici komutlar\u0131 \u00e7al\u0131\u015ft\u0131rmak i\u00e7in\n const app = express();\n const port = 3000; \/\/ MCP sunucusu bu portta dinleyecek\n\n \/\/ Gelen JSON isteklerini ayr\u0131\u015ft\u0131rmak i\u00e7in\n app.use(bodyParser.json());\n\n \/\/ Ana dizine basit bir GET iste\u011fi ile sunucunun \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 kontrol edelim\n app.get('\/', (req, res) => {\n res.send('MCP Sunucusu aktif ve bekliyor...');\n });\n\n \/\/ Webhook endpoint'i\n app.post('\/webhook', (req, res) => {\n console.log('Webhook tetiklendi!');\n \/\/ Burada Git platformundan gelen iste\u011fi do\u011frulamak i\u00e7in g\u00fcvenlik kontrolleri yap\u0131labilir.\n \/\/ \u00d6rne\u011fin, req.headers['x-github-event'] veya req.headers['x-gitlab-event'] kontrol edilebilir.\n\n \/\/ Blog deposunun bulundu\u011fu dizine ge\u00e7i\u015f yapal\u0131m\n const blogRepoPath = '\/home\/user\/my-blog-repo'; \/\/ Kendi Git deponuzun yolu\n const publishPath = '\/var\/www\/blog'; \/\/ Nginx'in blogu servis etti\u011fi yol\n\n exec(cd ${blogRepoPath} && git pull origin main && hugo --minify -d ${publishPath}<\/code>, (error, stdout, stderr) => {\n if (error) {\n console.error(Yay\u0131nlama hatas\u0131: ${error.message}<\/code>);\n return res.status(500).send('Yay\u0131nlama ba\u015far\u0131s\u0131z. Detaylar i\u00e7in sunucu loglar\u0131na bak\u0131n.');\n }\n if (stderr) {\n console.error(Stderr: ${stderr}<\/code>);\n }\n console.log(Stdout: ${stdout}<\/code>);\n res.status(200).send('Blog ba\u015far\u0131yla yay\u0131nland\u0131!');\n });\n });\n\n app.listen(port, () => {\n console.log(MCP Sunucusu http:\/\/localhost:${port} adresinde \u00e7al\u0131\u015f\u0131yor<\/code>);\n });\n <\/code><\/pre>\n<\/p><\/div>\nKar\u015f\u0131la\u015f\u0131lan \u0130lk Zorluklar ve Hata Ay\u0131klama Stratejileri<\/h3>\n
\n
Webhook Tetikleme Sorunlar\u0131 ve G\u00fcvenlik Do\u011frulamas\u0131<\/h4>\n
\n
\n const crypto = require('crypto');\n \/\/ ... di\u011fer kodlar ...\n\n app.post('\/webhook', (req, res) => {\n const signature = req.headers['x-hub-signature-256'] || req.headers['x-gitlab-token'];\n const secret = process.env.WEBHOOK_SECRET; \/\/ Ortam de\u011fi\u015fkeninden al\u0131nmal\u0131\n\n if (!signature || !secret) {\n console.warn('Webhook g\u00fcvenlik anahtar\u0131 veya imza eksik.');\n return res.status(403).send('Yetkilendirme ba\u015far\u0131s\u0131z.');\n }\n\n const hmac = crypto.createHmac('sha256', secret);\n const digest = 'sha256=' + hmac.update(JSON.stringify(req.body)).digest('hex');\n\n if (digest !== signature) {\n console.warn('Webhook imza do\u011frulama hatas\u0131.');\n return res.status(403).send('Webhook imza do\u011frulamas\u0131 ba\u015far\u0131s\u0131z.');\n }\n\n console.log('Webhook ba\u015far\u0131yla do\u011fruland\u0131.');\n \/\/ ... yay\u0131nlama komutlar\u0131 ...\n });\n <\/code><\/pre>\n<\/p><\/div>\n<\/li>\n<\/ul>\n<\/li>\nDosya \u0130zinleri ve Kullan\u0131c\u0131 Yetkilendirmesi<\/h4>\n
\n
Statik Site Jenerat\u00f6r\u00fc Entegrasyon Hatalar\u0131 ve Ortam De\u011fi\u015fkenleri<\/h4>\n
\n
Zaman A\u015f\u0131m\u0131 Sorunlar\u0131<\/h4>\n
\n
Performans Optimizasyonu ve G\u00fcvenlik \u00d6nlemleri<\/h3>\n
Performans Optimizasyonu:<\/h4>\n
\n
\n
\n
G\u00fcvenlik \u00d6nlemleri:<\/h4>\n
\n
\u0130leri D\u00fczey Otomasyon ve S\u00fcrekli Da\u011f\u0131t\u0131m (CI\/CD) Entegrasyonu<\/h3>\n
Test Ortamlar\u0131 ve Otomatik Testler:<\/h4>\n
\n
Dockerizasyon:<\/h4>\n
\n # Dockerfile \u00f6rne\u011fi\n # Node.js 18 Alpine tabanl\u0131 bir imaj kullan\u0131yoruz, hafif ve verimli\n FROM node:18-alpine\n\n # \u00c7al\u0131\u015fma dizinini belirliyoruz\n WORKDIR \/app\n\n # package.json ve package-lock.json dosyalar\u0131n\u0131 kopyal\u0131yoruz\n # Bu sayede ba\u011f\u0131ml\u0131l\u0131klar de\u011fi\u015fmedi\u011finde Docker katman\u0131 \u00f6nbellekten kullan\u0131l\u0131r\n COPY package*.json .\/\n\n # Ba\u011f\u0131ml\u0131l\u0131klar\u0131 y\u00fckl\u00fcyoruz\n RUN npm install\n\n # Geri kalan uygulama kodunu kopyal\u0131yoruz\n COPY . .\n\n # MCP sunucusunun dinleyece\u011fi portu belirtiyoruz\n EXPOSE 3000\n\n # Sunucuyu ba\u015flatma komutunu tan\u0131ml\u0131yoruz\n CMD [\"node\", \"server.js\"]\n <\/code><\/pre>\n<\/p><\/div>\nGeli\u015fmi\u015f \u0130\u015f Ak\u0131\u015flar\u0131:<\/h4>\n
\n
Sonu\u00e7: Kendi Yay\u0131nlama Sunucunuzla Elde Edilenler<\/h3>\n
S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h3>\n
\n