Kloia Blog

19 Dec 2016
by dsezen
Comments are closed

NewYear Lottery

newyear

2017 senesinin herkese şans ve başarı getirmesi dileklerimizle….

 

23 Aralık'a gelen başvurular arasında yapılan çekilişte hediye kazananlar altaki gibidir:

USB DevOps anahtarı : Oğuzhan Cengiz, Oktay Sabak, Onur Şimşek, Orhun Çıraklı

CloudFlare t-shirt: Numan Kaçar, Tuhanan Pehlivan, Emre Torun, Hülya Çakır

1 günlük eğitim katılım hakkı: Çağrı Özer

19 Dec 2016
by dsezen
Comments are closed

DevOps anahtarınız bizden!

DevOps'da bazı kapıları açmak zor, özellikle kültür işin içine girince… Biz her şirketin, kendine özel bir DevOps yolculuğu olması gerektiğine inanıyoruz. Bu yolculuk boyunca alınan geribildirimler ve yapılan deneyler ile alınması gereken kararlar ve güncellenmesi gereken birçok şey var: İletişim, süreçler, araçlar…

Sizler için bu yolculukla ufkunuzu açacağına inandığımız, "public" olarak indirilebilir dökümanları bir araya toplandık. Bunları da her zaman anahtarlığınızda taşıyabileceğiniz bir USB içerisine kopyaladık.

key4devops

 

 

14 Sep 2016
by dsezen
Comments are closed

HepFly Survives!

hepfly_survivor

HepFly ile tanışıklığımız ucakbileti.com döneminde olmuştu. One-click deployment, Micro-Services Architecture, Behavior-Driven Monitoring and Cloud gibi konularda birlikte keyifli zamanlarımız oldu. 

 

Survivor'a reklam verip de gelen trafik karşısında sıkıntı yaşayan websitelerini duymuşsunuzdur. Daha önce bu amaçla kapımızı çalan müşterilerimiz olmuştu. Herbiri için de custom çözümler üretmek durumunda kaldık. Bu gibi benzer ihtiyaçlarda benzer patternlar yakalayabilir miyiz düşüncesi ile hep başlarız ama inanın her yazılımın iç dinamiği ve DevOps pratiklerinin nasıl uygulanabileceği birbiri arasında çok fark ediyor.

 

jmeter-Blazemeter performans testleri için vazgeçilmez araçlarımız arasında

 

HepFly ile tek çalışma amacımız bu olmasa da, Survivor'a çıkacağı haberi geldiğinde, hemen yönümüzü değiştirip, performans testleri koşmaya başladık. Öncelikle site içerisindeki kullanıcı pattern ine göre jmeter testlerinin yazılması gerekli idi. Bunun analizi sonrasında BlazeMeter'ın da yardımı ile yüksek concurrency testleri koştuk. 30 civarı mikro servis içeren mimari içerisinde, Bottleneck olan servisler hemen kendilerini belli etti. Buradaki refactoring ve scaling düzenlemelerinde sonra hazırdık ve non-500 bir reklam süreci geçirdik. 

blazemeter

 

Monitoring Measurement

 

DevOps dünyasında özellikle monitoring demekten kaçınıyoruz. Bunun yerine Measurement kelimesine rastlamışsınızdır. Klasik tabir ettiğimiz, OSI L3, L4 bazlı monitoringin gerçek dünyada çok bir katmadeğeri yok ve gerçek kullanıcı deneyimini de yansıtmıyor. Bunun yerine gerçek bir kullanıcının deneyimlediği çıktının gözlemlenmesi, ölçümlenmesi ve buradaki değerleri kullanarak "Continuous Improvement" döngüsünün işletilmesini daha çok tercih ediyoruz.

 

NewRelic Insights, Behavior-Driven Monitoring ihtiyaçlarınıza cevap verebiliyor 

 

newrelic_synthetics

 

HepFly'ın da Behavior-Driven Monitoring ihtiyaçları karşısında zaten kullanmakta oldukları NewRelic'deki Insights kullanmaya karar verdik. Burada yazılan custom kodlar ile HTML elementlerinin parse edilip, gerçekten istenen çıktının kullanıcıya gösteririp gösterilmediğini ölçümleyerek, kullanıcı şikayet etmeden HepFly aksiyon alabilen hale geldi.

İlgili kod blogu alttaki gibidir, github'dan inceleyebilirsiniz.

var assert = require('assert');

$browser.get('https://www.domain.com').then(function(){
  return $browser.findElement($driver.By.className('search-list-container')).then(function(element){
    return element.findElement($driver.By.tagName('li')).then(function(element){
         return element.getAttribute('att01').then(function(text){
        	assert.equal("text2beequal", text, "not found");
      });
    });
  });
});

HepFly, DevOps yolculuğundaki attığı adımlar ile rekabetçiliğini artırarak, reaktif bir yapı yerine, proaktif bir düzen ile hizmet vermeye devam ediyor.

07 Sep 2016
by dsezen
Comments are closed

AWS Danışmanlık Deneyimlerimiz

AWS

AWS peşimizi bu aralar hiç bırakmıyor, bırakmasın da. Tanışıklığımız uzun zaman önce olan AWS, özellikle son senelerdeki ivmesi ile heryerde karşımıza çıkıyor, özellikle "Startup" larda. Bizim de onların süreçlerini otomatize etmek ve onları daha verimli hale getirmek hoşumuza gitmiyor değil.

 

Ağustos ayındaki bu fırsata eriştiğimiz şirketler hesapkurdu.com ve cibuu.com idi. İkisinin de yazılım stack leri birbirinden çok farklı, bir tarafta .NET&MSSQL, diğer tarafta node.js&redis&MySQL, ama ihtiyaçlar aynı: Automated Provisioning, One-click-Deployment, Automated Scaling. Tabii bunların yapılabilmesi için çoğu zaman yazılımın koduna da ucundan girilmesi gerekiyor. "Micro-refactoring" diyoruz biz buna kendi içimizde.

 

Bunlar dışında CloudFront'un esnek behavior bazlı kurallarını tek endpoint üzerinde sanki birden fazla CDN varmış gibi davrandırarak, kompleks ihtiyaçları da karşılayabildiğini kanıtladı. CloudFront-S3 ikilisi sayesinde de gerekmeyen durumlarda EC2 lardan kurtulup tasarruf sağladık.
 


Tabii ki hazır uğramışken AWS konfigurasyonlarındaki gözümüze çarpan yerleri de düzeltiyoruz, bu da bizden bonus olsun:)

06 Sep 2016
by dsezen
Comments are closed

CloudBees Jenkins Technical Bootcamp Notlarımız

cloudbees_jenkins_technical_boothcamp01

CloudBees partnerliğimiz çerçevesinde 29,30 ve 31 Ağustos'ta katıldığımız "CloudBees Jenkins Technical BootCamp" , versiyon 2.x ile birlikte, bize Jenkins'in ücra köşelerini keşfetme imkanı verdi. Özellikle "deep-dive" denecek düzeyde olan workshoplar, Jenkins'ın aslında bir denizden ziyade okyanus olduğunu bir kez daha bize gösterdi.

Yapılan bir araştırmada Jenkins, CI(Continuous Integration) Server kategorisinde ortalama %70 kullanım oranına sahip: 

jenkins

 

OpenSource Jenkins'in yanında, Enterprise CloudBees platformu üzerinde de workshoplar vardı. Özellikle büyüyen yapılarda Enterprise CloudBees Jenkins Platformu, tercih edilmesini gerektiren birçok özelliği içerisinde barındırıyor. Bunlar arasında:

  • Teknik ve danışmanlık desteği
  • Büyüyen yapılarda ölçeklenebilme
  • Monitoring ve analytics
  • Checkpoint ile build ı istenilen yerden tekrar başlatma
  • Rol bazlı yetkilendirme
  • ….

CloudBees Enterprise Platformunun diğer tüm özelliklerini buradan bulabilirsiniz.

cloudbees_jenkins_technical_boothcamp05

Workshop lar arasında öne çıkanlar:

  • CloudBees Jenkins Operations Center

    • Distributed Masters-Slave Architecture
    • Backup Scheduling
    • Analytics
    • High-Availability
    • Security with RBAC plugin
    • Cluster Operations
  • Unit-tests, Integrations-tests and UI Tests with Selenium
  • Code-Quality and Code Coverage
  • Parameterized Builds
  • Automated Deployments
  • Folders, Folders Plus
  • Validated Merge
  • Pull-request Builder
  • Templates
  • Pipeline

Docker artık "defacto" olarak kullanıldığını, birçok workshopta gösterdi:

cloudbees_jenkins_technical_boothcamp04 cloudbees_jenkins_technical_boothcamp03

CloudBees, OpenSource bir projenin Enterprise seviyede sunulabildiğinin güzel örneklerinden…

cloudbees_jenkins_technical_boothcamp06

11 Aug 2016
by dsezen
Comments are closed

n11.com DevOps kültürünü kloia danışmanlığı ile geliştiriyor

 

n11_dry-mstfa_ysf

Ülkemizdeki DevOps, yazılım mimari, test kültürü ve agile yazılım geliştirme olgunluk seviyesi her geçen gün daha iyiye gitmekle birlikte halen gelişmeye açık bir durumda. n11.com, TDD,pair-programming, Continuous Integration gibi yazılım geliştirme pratiklerini uygulayan n11, Türkiye'de bu alanlarda öncü firmalardan biri.

 

IMG_20160809_135705463.jpg

 

n11.com iddialı olgunluk seviyesini DevOps yolculuğundaki adımlarını sağlam atarak daha da ileriye taşımayı hedefliyor.

 

n11.com'daki yazılım geliştirme takımlarının katılımıyla, Amazon Web Services(AWS) üzerinde hands-on DevOps workshop'ları düzenledik. Ocak – Mayıs ayları arasında devam eden bu workshop'ların amacı n11.com'un DevOps yönünde iş yapış tarzının evrilmesine destek olmaktı.

IMG_20160809_135200362.jpg

 

 

 

Workshop'ları DevOps'un farklı prensip ve pratiklerinden oluşmakta idi. Hands-on uyguladığımız öne çıkan pratik ve prensipler arasında:

– Automated-provisioning

– Automated Deployment

– Zero-downtime Deployment: Rolling Deployment, Blue-Green Deployment

– Horizontal Auto-Scaling

– Container approach on Docker

– Continuous Delivery Pipeline on Jenkins with Docker

 

IMG_20160809_135138503_HDR.jpg

Workshop'ların başlıkları alttaki gibiydi:

  • DevOps Giriş
  • Infrastructure Giriş

    • OSI katmanları ve ağ yapılanması
    • Storage teknolojileri
    • Cloud vs on-premises
  • DevOps Compatible Software
  • AWS Giriş (EC2, S3, Cloudront, IAM, VPC, Route53)  + workshops
  • AWS Elastic Beanstalk + workshops
  • AWS Opsworks + workshop
  • AWS Cloudformation + workshop
  • AWS Codepipeline + workhop
  • Jenkins – ElasticBeanstalk workshop
  • Docker workshop
  • Jenkins – Docker – GitHub deployment pipeline workshop

devops_aws_academy

 
10 Aug 2016
by bilal
Comments are closed

Geçmişte Hudson, Günümüzde Jenkins

 

Bu yazımızda size Jenkins’in geçmişten günümüze nasıl evrildiğini ve 2016 Nisan ayında major release olan Jenkins 2.0’dan bahsedeceğim.

 

Hikayemiz 2005 yılında Sun MicroSystems’de çalışan Kohsuke Kawaguchi’nin Hudson isimli bir CI (Continous Integration) yazmasıyla başlıyor. Proje Sun MicroSystem’in bir alt projesi olarak hayata geçiyor. Ve proje geliştirildikçe popülerliği iyice artıyor. 2008 yılında JavaOne’da ayrıca bir ödüle layık görülüyor.

 

Oracle 2009 yılında Sun MicroSystems’i satın aldıktan sonra, projenin yönetimi de Oracle’a geçmiş oluyor. Projenin yönetimi Oracle’a geçtikten sonra, Oracle ile projeye sürekli katkıda bulunan developerlar arasında anlaşmazlıklar çıkıyor. Oracle “Hudson” projesini ticari bir marka haline getirmek istiyor ve bunu uygulama koyuyor. Bu sırada tartışmalar iyice alevleniyor, açık kaynak kodlu bir projenin ve buna gönüllü olarak destek veren yazılımcılar projenin bu şekile devam etmesini istemiyorlar.

 

11 Ocak 2011’de, Hudson’ın geliştiricileri, Hudson’ın bir kopyasını (fork) alarak, Jenkins adı altında projeyi geliştirmeye başlıyorlar. Oracle bu sırada, Jenkins’in Hudson’dan daha yavaş ilerleyeceğini açıklıyor.  Ancak Jenkinsin geliştiricileri bu konuda tam tersi şekilde düşünüyorlar. Ve zaman içinde ortalama gün başına commit sayısı Jenkins’te çok daha fazla olmaya başlıyor. Aynı şekilde, popülerlik olarakta Jenkins Hudson’ı geçiyor.

Şu an 410 contributoru bulunan Jenkins, aktif olarak geliştirilmeye devam ediyor. Ve Hudson ile başlayan bu hikayemiz 10 yıl aradan sonra ilk major releaseini yaptı. Bir çok yenilik gördüğümüz 2.x versiyonundan bahsedelim kısaca.

Jenkins 2.0 Yenilikleri:

  • Pipeline Özelliği

Jenkins 2.0 ile projeniz ile ilgili test,build etme, deploy gibi işlemleri bir pipeline olarak tanımlayabilirsiniz. Böylece projenizin tüm süreçlerini baştan sonra Jenkins üzerinden takip edebilirsiniz.

 

Resimde gördüğümüz gibi istediğimiz branchler için pipeline özelliğini aktif ediyoruz. Ve commit yaptıktan sonra projemizin hangi aşamalardan geçtiğini, bu aşamaların sonuçlarının başarılı/başarısız olduğunu gözlemleyebiliyoruz. Burada şöyle bir soru gelebilir aklımıza, bu pipeline’i nasıl yazacağız? Jenkins bunun için kendine özel bir DSL dili geliştirmiş, projenizin özelliklerine ve ihtiyaçlarınıza göre kendi Jenkins File’nizi yazıyorsunuz.

  • Daha Kullanışlı Bir Jenkins 2.0

Jenkins’in temelden beri en önemli özelliği plugin (eklenti) desteği sağlaması. Jenkins kullanıcıların plugin yazmalarını sağlayan bir api sunuyor. Böylece dışarıdaki yazılımcılar, ihtiyaçlarına göre veya genel ihtiyaca göre pluginler yazabiliyor. Örneğin, her buildden sonra log dosyalarınızı Amazon S3’e atmak istiyorsunuz, bunun ihtiyaç için illa birileri plugin yazmış oluyor ve sizde kendi Jenkins’inizde bunu kullanabiliyorsunuz.

 

Piyasada, iyi-kötü binlerce plugin bulunmakta. Ve probleminizi çözen bir çok plugin olabiliyor, ve hangi pluginin daha iyi olduğu konusunda kararsız kalabiliyorsunuz. İşte Jenkins 2.0 ile, Jenkins en çok kullanılan, sevilen ve kullanışlı pluginleri size öneriyor.

 

  • Multi-Configuration Projects

        Bu özellik benimde Jenkins 1.6’da çokca yaşadığım bir problemdi ve 2.0’da çözülmesine çok sevindim diyebilirim. Problemi şöyle açıklayabiliriz, projemi birden fazla environmentta test etmek istiyorum, örneğin Java 6-7-8’de ve farklı Java dağıtımlarında ( IBM,Oracle, OpenJDK) da build etmek istiyorum. Aslında baktığınız zaman bu buildlerin hepsinin konfigurasyonu aynı sadece JDK versiyonu ve dağıtımı farklı. Böyle olduğu zaman Jenkins 1.6’da her bir kombinasyon için farklı bir build oluşturmanız gerekiyordu. Ancak 2.0 ile, tek bir build oluşturup, build içerisinde bir konfigurasyon matrisi oluşturabiliyorsunuz. Böylece, Jenkins ekranında yüzlerce build yerine, kategoriler halinde buildler gözüküyor.

 

  • Diğer Jenkins Özellikleri

Jenkins 1.x de olan her özelliği 2.0’da kullanabiliyorsunuz. Bundan dolayı 2.0’a geçmek çok sancılı olmayacak gibi duruyor. Peki Jenkins’te neler yapabilirim bunlardan bahsetmek gerekirse:

  • Projelerinizi istediğiniz Docker imajları içerisinde build edebilirsiniz ( Docker Plugin)

  • Jenkins’e kendi sunucularınızı slave olarak tanıtıp, buildlerinizi o makinelerde yapabilirsiniz. ( windows makine tanıtmak mümkün)

  • Buildleriniz fail ettiği zaman, kendinize mail gelmesini sağlayabilir, Slack’e bildirim gitmesini ayarlayabilirsiniz.

  • Aws pluginleri ile, AWS servislerini kolayca kullanabilirsiniz.

  • Pull Request builder ile, BitBucket yada Github kullanıyorsanız, pull request geldiği zaman otomatik build edebilirsiniz.

  • Projenizde her commit geldiği zaman otomatik buildi ayarlayabilirsiniz.

Ve daha aklıma gelmeyen yüzlerce plugin ve özellik…

 
23 Jun 2016
by dsezen
Comments are closed

DockerCon16 deneyimlerimiz

dockercon16

kloia olarak davet edildiğimiz DockerCon16 konferansı 19-21 Haziran tarihlerinde Seattle'da gerçekleşti. Docker ve ekosistemi oyuncularının olduğu konferans, DevOps bakış açısıyla ulaşılacak uç boyutlardan örnekler yansıtıyordu.

Konferans boyunca aynı zamanda kloia.cloud servisimizin altyapısındaki konteyner ve replikasyon sihrini yapan Virtuozzo ekibi ile "deep dive" sohbetlere girme fırsatı bulduk.

dockercon16_bumpup

 

 

Öncelikle konferansa özel bir mobil uygulama ile tüm programın takibi, anlık bildirimler ve sosyalleşme sağlandı. Bunun üzerine bir de oyunlaştırma(Gamification) teknikleri kullanılarak interaktivite arttırılmaya çalışıldı. Bileklik sayesinde konferans sırasında tanıştığınız bir kişi ile bilekliklerinizi tokuşturarak puan topluyorsunuz ve kontaklarınızı paylaşabiliyorsunuz!

 

 

 

 

Konferans programını altta görebilirsiniz:

 

dockercon16_agenda

 

 

 

 

 

 

Docker'daki Beta, Experimental ve 1.12 ile gelen özellikler arasında:

 

1- Docker for Mac & Docker for Windows: Linux dışındaki işletim sistemlerinde Docker çalıştırmak için eskiden Kitematic ve boot2docker gibi araçlar kullanmanız gerekiyordu ve makinanız içinde açılan bir sanal makina(VM) aslında sizin Docker sunucunuz oluyordu. VM açmak için de VirtualBox gibi bir ek araca ihtiyaç duyuluyordu ve bunun yanında Kitematic&boot2docker gibi ek araçlar kullanmak gerekiyordu. Artık VirtualBox-Kitematic-boot2docker ı bigisayarınızdan silebilirsiniz, fakat native gibi çalışsa da aslında HyperKit ile çok daha lightweight bir VM arkada açıyor ama size tamamen transparan. Yani Docker Engine OSX de değil aslında, bu da altta zaten belli ediyor kendini:

dsezen$ docker version

Client:

 Version:      1.12.0-rc3

 API version:  1.24

 Go version:   go1.6.2

 Git commit:   91e29e8

 Built:        Sat Jul  2 00:09:24 2016

 OS/Arch:      darwin/amd64

 Experimental: true

 

Server:

 Version:      1.12.0-rc3

 API version:  1.24

 Go version:   go1.6.2

 Git commit:   876f3a7

 Built:        Tue Jul  5 02:20:13 2016

 OS/Arch:      linux/amd64

 Experimental: true

Mac&Windows download linkerine buradan erişebilirsiniz.

2- Docker for AWS & Docker for Azure: Nasıl Docker for Mac&Windows yazılımcılar için ise, Docker for AWS&Azure da operasyon takımlarının işini kolaylaştırmak ve otomasyonu arttırmak için ortaya çıktı. Docker tek başına bir yazılımı AWS veya Azure'da ayağa kaldırmaya yetmediği için, diğer gereksinimler olan yük dağıtıcı(LB), LB lerin yeni aktive olan konteynerler ile trafik yönlendirme güncellemeleri, güvenlik grupları(Security Groups), sanal ağlar(virtual networks) bileşenleri AWS Cloudformation ve Azure Resources Manager kullanılarak artık deploy etmek mümkün. Henüz private Beta olduğundan erişim talep etmeniz gerekiyor.

 

3- Routing Mesh: Doğası gereği yük dağıtıcılar (Load Balancers) konteynerden ziyade, üzerindeki çalıştığı makina(host) odaklı yönlendirme(routing) yaparlar. Her eklenen konteyner için, ilgili host a yönlendirme yapması için ilgili yük dağıtıcısının(LB) config dosyasını editlemek, tekrar yükletmek, reload etmek gibi, otomasyonu zahmetli işler gerekir.

Routing Mesh ile tüm swarm ı kapsayan bir port u, örnek 80, rezerve ederek üzerinde ilgili konteyner çalışsın çalışmasın, tüm makinalar 80 portuna gelen istekleri kabul ediyor ve DNS SRV ile ilgili servisi bularak, ilgili konteyner a yönlendiriyor. Yani LB nin artık hangi makinaya yönlendireceğinin yönetilmesine gerek kalmıyor. Bu yönlendirme, Linux kernel'da kendini ıspatlamış IPVS kullanılarak yapılıyor. Optimum bir çözüm mü? Optimumdan ziyade tam bir mühendislik kararı, yani artısı da var, eksisi de. Bence artısı şu aşamada bir tık ön planda gözüküyor.

 

4- Cryptographic Node Security: Artık mutual end2end TLS konteynerler arası mümkün ve Docker'daki güvenlik çekincelerinin biri çözülmüş oluyor. Arka planda kullanılan ise Notary ve TUF kullanarak bunu yapıyor. Sertifika oluşması ve konteynerlerin birbiri ile şifreli olarak haberleşmesi için yazılım seviyesinde birşey yapılmasına gerek yok.

 

5- Orchestration built-in&Services: Orchestation artık Docker'ın içerisinde geliyor. "Swarm Mode" aktive etmek için ana makina üzerinde 

docker swarm init

Swarm a katılmak isteyen diğer makinalar üzerinde

docker swarm join <swarm init yapılan IP>:2377 

yazmak yeterli, yani sadece 2 komut.

Bunun yanında uygulamamızın olması gereken state ini belirtmek mümkün. Örnek olarak app01 uygulamasını appnet ağı içerisinde 4 konteyner içerecek şekilde açmak için

docker service create –replicas 4 –name app01 –network appnet –publish 8080:8080/tcp app01_image:latest

yazıyoruz. 4 node u daha sonra yük dağıtımı (load balancing) için kullanıyor olacağız.

appnet ağını Docker'da yaratmak için

docker network create appnet

yazmak yeterli.

Örnek olarak redis servisini swarm a eklemek için.

docker service create –name redis –network appnet redis:latest

yazıyoruz.

Eğer ki app01 için belirtmiş olduğumuz 4 adet nodeun çalıştığı makinalardan bir şekilde down olan olursa, docker istenilen state 4'e ulaşmak için yeni nodeları mevcut makinalarda ayağa kaldıracaktır.

 

6- Scaling: 5 numaları bölümden referans alarak, eğer ki app01'imizin 6 node a çıkmasını istiyorsak,

docker service scale app01=6

yazmamız yeterli.

 

7- Service Discovery: Gene 5 numaralı bölümden referans olarak, eğer app01 uygulamamız redis ile çalışıyor olduğunu varsayalım, ama app01 redis endpoint ini bilmiyor. Docker DNS SRV seviyesinde yaptığı servis bulma (service discovery) sayesinde app01 in redis e ulaşması için hostname olarak "redis" yazması yeterli.

 

8- Global Services: Eğer ki tüm makinalarda çalışması gereken bir servis varsa, bunu global modunu kullanarak yapabiliyoruz. Buna örnek olarak makina üzerinde log ve metriklerin toplandığı bir uygulama olabilir. Bunu yapmak için:

docker service create –mode=global –name newrelic tutum/newrelc-agent

Böylece newrelic konteynerinin tüm makinalar üzerinde 1 kopyası çalışıyor oluyor.

 

8- Constraints: Belli bir makina veya makina grubunu belirli bir özelliğine(hardware, lokasyon, …) göre etiketleyerek, belirli tip etiketlere göre politika belirleyebiliriz. Örnek olarak belirli tip bir servisin sadece ssd disklere sahip makinada çalışmasını sağlayabiliriz. Veya konteynerler arası performans farkını düşürmek amaçlı, belirli tip bir batch işlemi, sadece belli tip serverlarda çalıştırmak isteyebilriiz.

Öncelikle etiketlemek için:

docker daemon –label storage="ssd"

Uygulamamızın sadece ssd diskli makinalarda çalışması için:

docker service create –replicas 4 –name app01 –network appnet –publish 8080:8080/tcp –constraint storage="ssd" app01_image:latest

 

9- Distributed Application Bundle: Artık birçok uygulama tek bir konteynerden ziyade, birçok konteynerin birlikte çalışmasını gerektirmekte. Bunu tanımlamak için docker compose daha önce kullanmaktaydık ama bu deployment için yeteli değildi. 

Experimental olarak yayınlanan bu özellik ile yazılım stack inizi .dab uzantılı text dosyası ile tanımlayabiliyosuz. Nasıl docker image ları Dockerfile kullanılarak oluşturuluyorsa, dab dosyaları da docker-compose.yml kullanılarak oluşturuluyor. Format olarak JSON olan dab dosyasında, uygulama için gereken tüm servisler, imagelar, port ve network bilgileri bulunmakta, yani Operasyon takımına deployment ı handover yapmak için birebir! 

dab dosyası oluşturmak için

docker-compose build

docker compose push

docker-compase bundle

Ops takımı için deploy etmek için ise

docker deploy file.dab

Eğer farklı uygulamalar için docker-compose.yml dosyalarımız varsa, örnek olarak micro services ortamlarında, bu komplex stack imizi tek bir dab dosyasında birleştirebiliyoruz.

 

06 Jun 2016
by dsezen
Comments are closed

DevOpsDays İstanbul 2016 notlarımız

Türkiye'de ve bölgede ilk kez gerçekleştirilen, kloia olarak bizim de organizasyon komitesinde olduğumuz, DevOpsDays İstanbul başarılı bir şekilde tamamlandı. Açıkçası DevOps bilincinin hala beklediğimiz seviyenin altında olduğu bir ortamda, biletlerin hepsinin satılmış olması, beklentimizin aksine bizi umutlandırdı ve mutlu etti.

Gerek konuşmacılar, gerekse de sponsorlar tarafından ilgi üst seviyede idi. Birbirinden değerli konuşmacılar arasından eleme yapmakta bu kadar zorlanacağımızı tahmin etmemiştik.

Türkiye'de bir konferansta ilk kez denenen "Open Space" (a.k.a. unconference) ile katılımcılar da aktif olarak konferansın seyrine, konuşulmasını istedikleri konu başlıkları önererek, oy vererek ve konuşmacı olarak rol oynadılar. Akabinde 6 adet farklı masa/oda içerisinde en fazla oy alan konular yüzyüze tartışıldı.

kloia masamızda Danışmanlık, kloia.cloud, XebiaLabs, Jenkins-Cloudbees, NewRelic, DBmaestro gibi DevOps odaklı çözümlerimiz hakkında bizim için çok değerli geri bildirimler aldık, bunları ödev olarak çalışmaya başladık.

DevOps-CaaS odaklı "Yeni nesil cloud" servisimiz kloia.cloud un demosunu yaparak, ilk kez bu konferansta bu ürünümüzü "Beta" olarak tanıtma fırsatı bulduk.

Konferanstan görseller:

devopsdays02 devopsdays01

Biraz da kloia dan:

kloia devopsdays rollups kloia devopsdays booth    

devopsdays_kloia01

Seneye organizasyonun büyüyerek devam etmesi dileklerimizle…

26 May 2016
by dsezen
Comments are closed

JenkinsDays Londra 2016

kloia olarak Cloudbees partnerliğimiz çerçevesinde 23-24 Mayıs'ta katıldığımız JenkinsDays Londra konferansında CI/CD(Continuous Integration/Continuous Delivery) ekosistemini yakından takip etme fırsatı yakaladık.

İlk gün tamamen ekosistemdeki oyuncular odaklı olan konferansın ikinci günü sadece Cloudbees partnerleri içindi.

kloia olarak bu ekosistemde sadece Türkiye değil, bölgedeki tek oyuncu olarak yer aldık:

cloudbees jenkins kloia

 1. gün dahilindeki katılımcı şirketler arasıda XebiaLabs, Sonatype ve Sumologic akıllarda yer eden şirketler arasında idi.

XebiaLabs, aynı zamanda partnerlik sürecine başladığımız DevOps yönünde XLRelease ve XLDeploy gibi, süreci uçtan uca kapsayan ürünleri piyasada barındıran bir şirket. XebiaLabs'in sektördeki konumlanmasını birebir tartıştık ve workshoplarına katıldık.

Sumologic ise, özellikle AWS ile birebir entegre, tüm log yapınızı emanet edebileceğiniz SaaS olarak konumlandırılmış bir ürün.

SonaType'ı ise Sonar ile katıştırmayın; yazılımınızın bağımlı olduğu komponentlere odaklanmış bir ürün. Tüm komponentlerin security, compliance ve bug durumlarını sizin yerinize yönetip, deployment pipeline da söz sahibi olabiliyor.

Konferansın bir kriket sahasının etrafında yapılması ilginç bir detay idi, ön tarafta sunumlar varken, arka planda kriket oynayanları görebiliyorsunuz:

circket devops jenkinsdays

Jenkins 2.0 üzerine birçok seans yapıldı. Özellikle "pipeline-as-code" ve "deployment pipeline" değişiklikleri dikkat çekici idi:

jenkins2 jenkins2

Özellkle whale.push() a dikkatinizi çekerim, ne olduğunu tahmin edenleriniz vardır.

Türkiye'de de bir gün olmasını arzuladığımız bir etkinlik idi, özellikle workshop yaklaşımı bizim de kloia olarak eğitimlerimizde uyguladığımız yaklaşımımız paralelinde idi.

 

DevOps Consulting © 2017