Kloia Blog

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.

 

18 Apr 2016
by dsezen
Comments are closed

What is DevOps?

 

DevOps is a mindset, which fosters the collaboration between the Development Team "Dev" , who is responsible from the production, and the Operation Team "Ops" , who is responsible from the execution.

 

DevOps approach fosters automation along application lifecycle, which vanishes the adhoc operations between Dev and Ops teams, and boosts  the quality by favoring software engineering practices and frequent live deployments with less incidents

 

DevOps enables the companies to adapt faster to the changes in the market by automating the manual approach which is open to failure. Beside, DevOps helps the infrastructure to be used more efficiently, decreasing the OPEX. In other words, one that does not apply DevOps practices, will not be in the market in the future.

 

DevOps is cultural shift rather than just a tool change. This shift must be supported with the right tools, which at the end enables "self-service IT" approach. Beside, the right engineering practices help the defect feedback loop in hours, rather than days, sometimes weeks, which is cognitively effective as developers make fixes rightaway.

 

What is DevOps, what is not DevOps?

  • DevOps is not a target, it is a journey.
  • DevOps is not a tool or an on-the-shelf software.
  • Each organisation has their own DevOps journey. 
  • DevOps is not a title, not a responsibility given only to one, rather it is mindset embraced by all.

 

DevOps fosters:

  • Higher quality, faster, more frequent live deploys.
  • Continuous Improvement cycle to be faster.
  • Transparency and collaboration between "Dev" and "Ops" teams.
  • Cost-cutting by effectively usage of the resources.

 

Agile Development Teams can only provide end-to-end agility by embracing the DevOps mindset. The following are the common symtoms otherwise:

 

  • "Push" approach is common rather than "Pull"
  • Change Lead Time is long.
  • Developers lately get the defect feedbacks.
  • New environment provisioning takes days/weeks.
  • Live environment has defects which does not show up during testing.
  • Infrastructure investment was done for the worst case scenario, which means waste.

 

Development team, owning all the responsibility of the cycle end-to-end is also a good practice which can be possible with the latest Cloud/PaaS/SaaS. Particularly, micro-services architectures enables end-to-end responsibility.

 

Software Development Cycle is defined as a flow which turns an idea into a working software. The following should be considered while defining the flow:

 

Continuous Integration(CI): Frequent integration of the code of different team members, preferably daily. Integration means, merging the code and pass from the unit-tests and detection of the errors during build.

 

Continuous Delivery(CD): CD checks the output of the CI, which is an artifact, to be a release candidate or not. This is done, by the automated deployment of the artifact on a prod-like environment and running the functional and non-functional tests.

 

DevOps is the organizational mindset that enables Continuous Delivery.

–Jez Humble

 

Continuous Deployment: Deployment of the release candidate onto the production environment automatically, which means each artifact passes is deployed.

 

09 Apr 2016
by dsezen
Comments are closed

Neden Docker?

before_containersYük taşımacılığı eski zamanlardan beri varolan bir ihtiyaç. Kargo gemileri ile bu yükler yüzyıllar boyunca bir limandan diğerine taşındı. Çoğu zaman kargoların gemiden boşaltılması ve yeni kargoların yüklenmesi için geçen süre, geminin denizde geçirdiği süreye kıyasla daha fazla sürmekte idi. Kargolar gemiden tek tek indiriliyor ve kamyonlara yükleniyor, yeni yükler ise gene kamyonlardan tek tek indirilip gemiye yükleniyordu. Bunun yanında içiçe taşınan bazı yükler, birbirleri ile nem ve koku olarak karışıyor, ve malların kalitesini etkiliyordu.

 

1955 yılında, Malcom P.McLean, günümüz konteyner yapısı olan, "intermodal" taşımacılık olarak da bilinen, farklı ortamlar(karayolu, denizyolu, havayolu) arasında transferin sorunsuz olması ve dok işçilerine daha az bağımlı hale gelinmesini sağlayan yapıya geçişin öncüsü olmuştur. Bu yaklaşım sayesinde konteyner ve aynı kargo, en az etkileşim ile, başlangıç noktasından, varış noktasına sorunsuz olarak teslim edilmeye başlanmıştır.

 

Son zamanlarda yazılım geliştirme sektöründe de adını sıkça duymaya başladığımız "container" yaklaşımının çözmeye çalıştığı sorunlar da benzerdir. Yazılım geliştirme sektörü taşımacılık ve üretim sektörünün uzun zaman önce çözmüş oldukları verimlilik sorunlarını henüz çözememiştir ve bu açıdan bakıldığında henüz emekleme safhasındadır.

 

Docker en çok bilinen ve kullanılan  "container" yapısı olarak yazılım geliştirme ve altyapı yönetim takımlarının hayatlarına girmeye başlamıştır.

 

docker_sticker_lineNeden Docker?

 

1- Para tasarrufu: Docker, sanal sunucuların (VM) aksine bir Hypervisor(VMWARE) katmanına ihtiyaç duymaz, dolayısıyla bu yöndeki lisans giderleriniz sıfırlanacaktır. Her Docker Container aynı işletim sistemi Kernel'ı üzerinde çalışır, yani VM'lerin aksine tek bir HW üzerinde farklı kernel ve işletim sistemleri yoktur. Tek bir işletim sistemi olmasının da lisans maliyeti açısından tasarrufu vardır. 

 

Docker kullanılan altyapılarda Hypervisor(VMWARE, …) ve OS(İşletim Sistemi) lisans maliyetlerinde ciddi tasarruflar sağlanabilir. 

 

2- Düşük footprint: Sunucu işletim sistemleri öntanımlı olarak üzerinde birçok servis, kütüphane ve dosya ile birlikte gelir ama Docker yaklaşımı ile birlikte gelen düşük "footprint" kullanımı sayesinde yazılımlar sadece ihtiyaç duyduğu bağımlılıklar ile çalışır ve sanal sunuculara (VM) kıyasla storage kullanımı çok düşüktür.

 

Docker kullanarak Storage gereksinimlerinizde tasarruf sağlayabilirsiniz.

3- İzolasyon: Aynı işletim sistemi üzerine farklı yazılım ve servislerin kurulumunun yapıldığına sıkça şahit oluruz. Bunun nedenleri arasında:

 

– Sunucu kaynaklarını daha verimli kullanmak, lisans maliyetleri,

– Sunucu/VM kaynak sayısının, sunulması gereken servise göre daha az olması. 

– Farklı işletim sistemleri ile uğraşmak istemememiz (Yönetim maliyeti)

olabilir.

 

Bu yaklaşım alttaki riskleri barındırabilir:

– İç içe giren kütüphane, dosya, konfigurasyon gibi bağımlılıklar

– Yapılan bir hata sonucu, İşletim Sistemi üzerindeki tüm servislerin aynı anda etkilenmesi

– Taşıma (migration) gibi operasyonların birçok farklı yazılımı aynı anda kapsaması gerektiğinden dolayı kompleks olması

 

Buna karşılık her Docker konteynerı kendi Namespace'inde çalışır, yani aynı işletim sisteminin Kernel'ını kullanmalarına rağmen, birbirlerini görmezler. Her konteynerde init prosesi (0 ID'li proses) servisin kendisidir(Örnek tomcat bir sunucunun init prosesi Java'dır). Bu yaklaşım sayesinde, Docker konteynerlerin farklı ortamlar, farklı servis sağlayıcılar veya farklı teknolojiler arasında taşınması basit bir operasyon haline gelir.

 

4- Daha hızlı ve verimli kod atım(deploy) süreci: Ortamlar(Dev, Test, Live) arasındaki farklar nedeniyle oluşan beklenmedik durumları Docker konteynerler kullanarak kökten çözmek mümkün. Lokal ortamınızda neyi test ediyorsanız, Live ortamda da aynı şekilde çalışacaktır. Bunun yanında Docker konteynerlerini tanımladığımız Dockerfile'ları, Git üzerinde versiyon kontollü olarak tutmak da büyük bir avantaj. Üstelik artık birçok Cloud sağlayıcıda(AWS, Azure, IBM Bluemix…) ve birçok CI(Continuous Integration) araçlar(Jenkins, Shippable, ..) Docker kullanarak versiyon Deploy yapmak mümkün.

 

5- Teknoloji bağımlılıklarının yok edilmesi: Kullanmakta olduğumuz Cloud sağlayıcı(AWS, Azure, IBM Bluemix) veya teknoloji sağlayıcısı(HP, IBM, Microsoft, …) size kendi araç ve teknolojilerini kullanmaya teşvik edecektir ve bu da beraberinde artık o teknolojiden kopamayacağınız seviyelere sizi getirebilir. Buna karşılık Docker konteynerleri artık herhangi bir servis sağlayıcı ve teknoloji üzerinde çalıştırabilir ve başka altyapı veya servis sağlayıcısına geçiş yapmanız çok kolaylaşır.

 

6- Ölçeklendirme (Scaling) : VM kullanan yapılarda sunucuların yatay veya dikey olarak büyüyüp küçülmesi dakikalar mertebesinde iken, Docker konteyner lerin açılıp kapanması saniyeler mertebesindedir. Bu bakımdan trafiğe göre sisteminizin ölçeklenmesi saniyeler içerisinde olabilmektedir. 

 

İsmi sıkça "Mikro servisler" ile anılan Docker, aslında mevcut dağıtık veya monolitik mimariniz üzerinde de kullanılabilir. Sonuç olarak Docker mimarisine geçiş yapmak, verimlilik açısından kaçınılmazdır. Aksi halde rekabet dezavantajı orta ve uzun vadede hissedilecektir.  

 

 

30 Mar 2016
by dsezen
Comments are closed

DevOps ve Agile

 

 

DevOps ve Agile birbirinin rakibi değildir ve farklı alanlara dokunduklarından dolayı birbirini tamamlayıcı niteliklere sahiplerdir. 

Agile yaklaşımlar müşteri ile geliştirme takımı arasındaki süreçlere odaklanırken, DevOps ise geliştirme takımı ve Operasyon takımları arasındaki süreçlere odaklanır.

Agile, bir User Story'nin geliştirmesinin tamamlanmasına kadar olan süreç ile ilgilenir, fakat geliştirme sonrasındaki süreç olan

  • Release/Deployment
  • Continuous Delivery
  • Infrastructure Automation
  • Monitoring/Measurement
  • UAT Automation

konularını açıkta bırakmaktadır. DevOps ise Developer ve Operasyon birimlerini birbirlerine yaklaştıran süreçleri teşvik ederek, bu açığı kapatmak ve uçtan uca çevikliğin sağlanmasını amaçlamaktadır.

Özellikle System Admin/Altyapı tarafından gelenler bilir ki, müşteri tamamlanan koddan ziyade vitrininizdeki kodu görür, dolayısıyla Agile 'in dokunduğu alana kıyasla daha hassas ve göz önünde bir alandır. DevOps işte bu ve Agile süreçlerin zayıf olduğu alanlara odaklanarak uçtan uca çevikliğin sağlanmasına yardımcı olur.

2 tarafın dokunduğu alanlar açısından ufak bir tablo hazırladım:

Agile   DevOps
Embrace change   Embrace testing & Delivery
Embed customer in team   Embed Ops in team
Soft skills + Engineering   Engineering

 

Bir diğer önemli husus ise DevOps üzerinde odaklanmış takımlardaki (Bunun bir rol/takım olması her ne kadar bir anti-pattern ise[1] de piyasada görüyoruz) Dev ve Ops tecrübelerinin dengeli olması gerekliliğidir. Sadece Developer background undan gelenlerde odak Continuous Delivery ve Containerization olurken, Sistem Admin tarafından gelenlerde scaling, fault tolerence, automated provisioning gibi alanlar olabilmektedir. İşte bu bakımdan DevOps rolü/takımının pratikte bu iki alandan birini boşta bırakma riski vardır. Fakat hem Dev, hem de Ops tarafında tecrübesi olan bir DevOps takımı, organizasyondaki mevcut takımlara, yürütme ve geliştirmeyi onlara bırakacak şekilde, bu kültürü aşılama rolü oynayabilir…

DevOps ve Agile ı, genel "Organizational Agility" altında düşünerek, alttaki gibi resmetmeye çalıştım:

Benim gördüğüm ve tecrübe ettiğim üzere tek kesişimleri Lean prensiplerdir. Hem Agile, hem de DevOps, günün sonunda 3 temel Lean günahını [2] yoketmeye çabalarlar.

Agile ve DevOps 'un ölçümlediği metrikler de bu doğrultuda farklılıklar göstermektedir:

Agile KPIs   DevOps KPIs
Innovation Rate   Deploy Frequency
Usage Index   Change Lead Time
Strategic Alignment Index   MTTR(Mean-time to recovery)
Velocity   MTBF(Mean-time between failuers)
Customer Satisfaction Index   Change Failure Rate

 

Deployment frequency boyutunda, günlük defalarca automated Live a çıkan takımlarda/ürünlerde, yani Continuous Deployment pratiğinde, Scrum gibi iteratif framework ler stres altında kalmaktadır.

İki konunun birbirinden farklı uzmanlıklar gerektirdiğini, bazı acquisition örneklerinden [3] de referans alabiliriz.

DevOps yolculuğunuzda sadece Dev değil, Ops üzerinde de uzmanlığın yer aldığından mutlaka emin olun

Bunu söylememin nedeni, özellikle Türkiye'de DevOps=Dev i çok fazla görüyor olmam.

DevOps yolculuğu Agile yolculuğunun stres altına bıraktığı organizasyon yapısına dokunmaz, yani Agile yolculuğunuz kadar riskli değildir, mevcut yapıya enjekte edilebilir.

DevOps'un, Development'ı outsource etmiş, ama Operasyonu içeride tutan şirketler için gün1 value sağlamaya başladığı alanlar bulunmaktadır.

[1] : http://martinfowler.com/bliki/DevOpsCulture.html

[2] : http://www.panview.nl/en/lean-production-toyota-3m-model/toyota-3m-model-muda-mura-muri

[3] : http://www.crn.com/news/cloud/300074831/vmware-acquires-professional-services-firm-to-boost-cloud-migration-devops-expertise.htm

 

 

Cloud, DevOps and Microservices Solution Provider © 2025