Gereksinimler<\/h2>\n\n- Docker<\/li>\n
- Kubernetes<\/li>\n
- Helm3<\/li>\n
- MSSQL<\/li>\n
- dotnet-ef tool<\/li>\n<\/ul>\n
Ben geli\u015ftirme ortam\u0131 olarak Docker Desktop’un Kubernetes \u00f6zelli\u011fini kullanaca\u011f\u0131m.<\/p>\n
\u00d6rnek Projeye G\u00f6z Atal\u0131m<\/h2>\n
\u00d6ncelikle migration i\u015flemleri i\u00e7in .NET 5<\/strong> ve EF Core<\/strong> kullanarak haz\u0131rlad\u0131\u011f\u0131m buradaki<\/strong><\/em><\/a>\u00a0 \u00f6rnek projeyi inceleyelim.<\/p>\nMigration i\u015flemlerini ana uygulamadan ayr\u0131 bir \u015fekilde ger\u00e7ekle\u015ftirebilmek i\u00e7in, “Todo.DbMigration<\/em>” ad\u0131nda bir console application olu\u015fturdum. \u0130\u00e7erisinde ise basit olarak “IDesignTimeDbContextFactory<\/em>” interface’ini, “Todo.Data<\/em>” library’sindeki “TodoDbContext<\/em>” i kullanarak implemente ettim.<\/p>\n\nusing System.IO;\r\nusing Microsoft.EntityFrameworkCore;\r\nusing Microsoft.EntityFrameworkCore.Design;\r\nusing Microsoft.Extensions.Configuration;\r\nusing Todo.Data;\r\n\r\nnamespace Todo.DbMigration\r\n{\r\n public class TodoDbContextFactory : IDesignTimeDbContextFactory<TodoDbContext>\r\n {\r\n public TodoDbContext CreateDbContext(string[] args)\r\n {\r\n var configuration = new ConfigurationBuilder()\r\n .SetBasePath(Directory.GetCurrentDirectory())\r\n .AddJsonFile(\"appsettings.json\")\r\n .AddEnvironmentVariables()\r\n .Build();\r\n\r\n var dbContextOptionsBuilder = new DbContextOptionsBuilder<TodoDbContext>();\r\n \r\n var connectionString = configuration\r\n .GetConnectionString(\"SqlConnectionString\");\r\n \r\n dbContextOptionsBuilder.UseSqlServer(connectionString, x => x.MigrationsAssembly(\"Todo.DbMigration\"));\r\n \r\n return new TodoDbContext(dbContextOptionsBuilder.Options);\r\n }\r\n }\r\n}<\/pre>\n<\/div>\n“Todo.Data<\/em>” library’sindeki db context ise a\u015fa\u011f\u0131daki gibidir.<\/p>\n\nusing Microsoft.EntityFrameworkCore;\r\nusing Todo.Data.Models;\r\n\r\nnamespace Todo.Data\r\n{\r\n public class TodoDbContext : DbContext\r\n {\r\n public TodoDbContext(DbContextOptions<TodoDbContext> options)\r\n : base(options)\r\n {\r\n\r\n }\r\n\r\n public DbSet<TodoEntity> Todos { get; set; }\r\n\r\n protected override void OnModelCreating(ModelBuilder modelBuilder)\r\n {\r\n modelBuilder.Entity<TodoEntity>()\r\n .HasKey(x => x.Id);\r\n modelBuilder.Entity<TodoEntity>()\r\n .Property(p => p.Name)\r\n .HasMaxLength(150)\r\n .IsRequired();\r\n }\r\n }\r\n}<\/pre>\n<\/div>\nInitial migration’\u0131 olu\u015fturabilmek i\u00e7in ise, projenin root klas\u00f6r\u00fcnde a\u015fa\u011f\u0131daki komutu \u00e7al\u0131\u015ft\u0131rd\u0131m.<\/p>\n
\ndotnet ef migrations add InitialCreate --project .\/Todo.Migration<\/pre>\n<\/div>\n![\"\"](\"data:image\/svg+xml;base64,PHN2ZyB3aWR0aD0iMSIgaGVpZ2h0PSIxIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjwvc3ZnPg==\")
<\/a><\/p>\nKubernetes Jobs<\/h2>\n
Kubernetes jobs, bize sonlu i\u015flemlerimizi \u00e7al\u0131\u015ft\u0131rabilece\u011fimiz bir yap\u0131 sunmaktad\u0131r. T\u0131pk\u0131 bir controller’\u0131n fail olmu\u015f bir pod’u “reschedule” veya “restrart” etti\u011fi gibi, kubernetes jobs da sonlu olan i\u015flemlerimizin ba\u015far\u0131yla \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flamaktad\u0131r.<\/p>\n
Kubernetes jobs ile olu\u015fturulan bir pod e\u011fer fail olmad\u0131 ve ba\u015far\u0131yla exit oldu ise, ilgili job ba\u015far\u0131yla tamamlanm\u0131\u015f olarak kabul edilmektedir. Bu i\u015flemi ise deploy etti\u011fimiz bir job’\u0131n “completion” durumunu sorgulayarak ger\u00e7ekle\u015ftirebiliriz.<\/p>\n
Ayr\u0131ca bir job silindi\u011finde ise olu\u015fturmu\u015f oldu\u011fu pod’lar da otomatik olarak silinmektedir. Fakat job tamamland\u0131\u011f\u0131nda otomatik olarak silinmemektedir. Silinme i\u015flemi ise job’\u0131n completion durumu sorgulanarak, manuel olarak ger\u00e7ekle\u015ftirilmelidir. Bu i\u015fleme ise birazdan de\u011finece\u011fiz.<\/p>\n
Toparlamak gerekirse kubernetes jobs, \u00f6zellikle batch veya migration gibi senaryolar i\u00e7in harika bir uyum sa\u011flamaktad\u0131r.<\/p>\n
Job Helm Chart Template’i Olu\u015ftural\u0131m<\/h3>\n
Ben deployment i\u015flemleri i\u00e7in productivity’i artt\u0131rd\u0131\u011f\u0131, tekrar kullan\u0131labilirli\u011fi sa\u011flad\u0131\u011f\u0131 ve bir standardizasyon kazand\u0131rd\u0131\u011f\u0131 i\u00e7in helm’i kullanmay\u0131 tercih ediyorum. Bu y\u00fczden job deployment i\u015flemi i\u00e7in de bir helm chart kullanaca\u011f\u0131z.<\/p>\n
Bunun i\u00e7in \u00f6ncelikle bir job helm chart template’i olu\u015fturmam\u0131z gerekmektedir.<\/p>\n
\u015eimdi projenin root klas\u00f6r\u00fcnde bulunan “helm-charts<\/em>” path’ine giderek, a\u015fa\u011f\u0131daki komut ile bir initial helm chart template’i olu\u015ftural\u0131m.<\/p>\n\nhelm create migration-job<\/pre>\n<\/div>\nArd\u0131ndan chart i\u00e7erisindeki “templates<\/em>” klas\u00f6r\u00fc i\u00e7erisinde bulunan “_helpers.tpl<\/em>” dosyas\u0131 hari\u00e7 geriye kalan t\u00fcm dosyalar\u0131 silelim.<\/p>\n\u015eimdi “templates<\/em>” klas\u00f6r\u00fc alt\u0131nda “job.yaml<\/em>” dosyas\u0131n\u0131 a\u015fa\u011f\u0131daki gibi tan\u0131mlayal\u0131m.<\/p>\n\napiVersion: batch\/v1\r\nkind: Job\r\nmetadata:\r\n name: {{ include \"migration-job.fullname\" . }}\r\nspec:\r\n backoffLimit: 0\r\n template:\r\n spec:\r\n containers:\r\n - name: {{ .Chart.Name }}\r\n image: \"{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}\"\r\n restartPolicy: Never\r\n {{- with .Values.nodeSelector }}\r\n nodeSelector:\r\n {{- toYaml . | nindent 8 }}\r\n {{- end }}<\/pre>\n<\/div>\nBu spec’deki dikkate almam\u0131z gereken k\u0131s\u0131m restrartPolicy <\/strong>ve backoffLimit<\/strong> dir. Ben herhangi bir ba\u015far\u0131 veya hata durumlar\u0131nda migration gibi i\u015flemler i\u00e7in pod’un\/container’\u0131n tekrar ba\u015flat\u0131lmas\u0131n\u0131 istemedi\u011fimden dolay\u0131 bu policy’leri “0” ve “Never” olarak ayarl\u0131yorum. (Elbette baz\u0131 istisnai durumlar kar\u015f\u0131s\u0131nda bunun da garantisi yok) Aksi taktirde “backoffLimit” default olarak “6” oldu\u011fu i\u00e7in, job, hata veren pod’u tekrar ve tekrar ba\u015flatmay\u0131 deneyecektir.<\/p>\nAyr\u0131ca bu configuration ile, o anki olu\u015fan hatan\u0131n neyden dolay\u0131 kaynakland\u0131\u011f\u0131n\u0131 bulabilmemiz de kolayla\u015facakt\u0131r.<\/p>\n
Value dosyas\u0131n\u0131 ise a\u015fa\u011f\u0131daki gibi g\u00fcncelleyelim.<\/p>\n
\nimage:\r\n repository: mytodoapp-migration\r\n tag: \"v1\"\r\n\r\nnodeSelector:\r\n beta.kubernetes.io\/os: linux<\/pre>\n<\/div>\nB\u00f6ylece helm chart template’i haz\u0131r durumda. \u015eimdi tek yapmam\u0131z gereken, \u00f6rnek projeyi “mytodoapp-migration:v1<\/em>” tag’i ile containerize bir hale getirmek.<\/p>\nContainerize Edelim<\/h2>\n
“Todo.DbMigration<\/em>” projesi i\u00e7erisinde a\u015fa\u011f\u0131daki gibi bir Dockerfile<\/strong> bulunmaktad\u0131r.<\/p>\n\nFROM mcr.microsoft.com\/dotnet\/runtime:5.0 AS base\r\nWORKDIR \/app\r\n\r\nFROM mcr.microsoft.com\/dotnet\/sdk:5.0 AS build\r\nWORKDIR \/src\r\nCOPY [\"Todo.DbMigration\/Todo.DbMigration.csproj\", \"Todo.DbMigration\/\"]\r\nRUN dotnet restore \"Todo.DbMigration\/Todo.DbMigration.csproj\"\r\nCOPY . .\r\nWORKDIR \"\/src\/Todo.DbMigration\"\r\nRUN dotnet build \"Todo.DbMigration.csproj\" -c Release -o \/app\/build\r\n\r\nFROM build AS publish\r\nRUN dotnet publish \"Todo.DbMigration.csproj\" -c Release -o \/app\/publish\r\n\r\nFROM base AS final\r\nWORKDIR \/app\r\nCOPY --from=publish \/app\/publish .\r\nENTRYPOINT [\"dotnet\", \"Todo.DbMigration.dll\"]<\/pre>\n<\/div>\n\u015eimdi projenin root klas\u00f6r\u00fcnde a\u015fa\u011f\u0131daki komutu \u00e7al\u0131\u015ft\u0131rarak migration uygulamas\u0131n\u0131 containerize bir hale getirelim.<\/p>\n
\ndocker build -f .\/Todo.DbMigration\/Dockerfile . -t mytodoapp-migration:v1<\/pre>\n<\/div>\n<\/a><\/p>\n<\/h2>\nDeploy Edelim<\/h2>\n
\u00d6rnek uygulamay\u0131 containerize bir hale getirdi\u011fimize g\u00f6re, deployment i\u015flemini ger\u00e7ekle\u015ftirebiliriz.<\/p>\n
Bunun i\u00e7in projenin root klas\u00f6r\u00fcnde bulunan “helm-charts<\/em>” path’ine giderek, a\u015fa\u011f\u0131daki helm komutunu \u00e7al\u0131\u015ft\u0131ral\u0131m.<\/p>\n\nhelm upgrade --install --values .\/migration-job\/values.yaml mytodo-migration .\/migration-job<\/pre>\n<\/div>\n<\/a><\/p>\n\u00d6rnek migration uygulamam\u0131z deploy olmu\u015f durumda.<\/p>\n
Peki \u015fimdi neler yapabiliriz?<\/h3>\n
\u00d6ncelikle a\u015fa\u011f\u0131daki komutu kullanarak job’\u0131n ba\u015far\u0131yla tamamlan\u0131p tamamlanmad\u0131\u011f\u0131n\u0131 kontrol edelim.<\/p>\n
\nkubectl get job<\/pre>\n<\/div>\n<\/a><\/p>\nG\u00f6rd\u00fc\u011f\u00fcm\u00fcz gibi deploy etti\u011fimiz migration uygulamas\u0131n\u0131n “COMPLETIONS<\/em>” durumuna bakarak, ba\u015far\u0131yla tamamlan\u0131p tamamlanmad\u0131\u011f\u0131n\u0131 anlayabiliriz.<\/p>\nE\u011fer herhangi bir hata meydana gelseydi, job’\u0131n olu\u015fturdu\u011fu ilgili pod’un log’lar\u0131na bakarak ilgili hatan\u0131n izini de s\u00fcrebilirdik.<\/p>\n
Migration sonucunu SQL Server’a ba\u011flanarak kontrol etti\u011fimizde ise, ilgili migration’\u0131n ba\u015far\u0131yla uyguland\u0131\u011f\u0131n\u0131 g\u00f6rebiliriz.<\/p>\n
<\/a><\/p>\nAyr\u0131ca bir job’\u0131n tamamland\u0131\u011f\u0131nda otomatik olarak silinmedi\u011finden de bahsetmi\u015ftik. Silme i\u015flemini ger\u00e7ekle\u015ftirmek i\u00e7in ise, a\u015fa\u011f\u0131daki standart helm komutunu kullanabiliriz.<\/p>\n
\nhelm delete mytodo-migration<\/pre>\n<\/div>\nPeki diyelim ki biz bu i\u015flemleri automated bir hale getirmek istiyoruz. \u00d6rne\u011fin Azure DevOps<\/strong> kullan\u0131yoruz ve ilgili migration job’\u0131n\u0131n, ba\u015far\u0131yla tamamlanmas\u0131ndan sonra otomatik olarak silinmesini istiyoruz.<\/p>\nBu i\u015flemi ger\u00e7ekle\u015ftirebilmek i\u00e7in ise, “kubectl<\/em>” in “wait<\/em>” komutundan yararlanabiliriz. Bir ba\u015fka de\u011fi\u015fle ilgili job’\u0131 silmeden \u00f6nce, bekleme i\u015flemini job tamamlanana kadar s\u00fcrd\u00fcrmemiz gerekmektedir.<\/p>\nBunu ise a\u015fa\u011f\u0131daki komut yard\u0131m\u0131 ile yapabiliriz.<\/p>\n
\nkubectl wait --for-condition=complete job\/mytodo-migration-migration-job --timeout=2m<\/pre>\n<\/div>\n<\/a><\/p>\n<\/a><\/p>\nG\u00f6rd\u00fc\u011f\u00fcm\u00fcz gibi belirtti\u011fimiz condition ger\u00e7ekle\u015fene kadar ilgili task, timeout s\u00fcresi boyunca bekletilecektir. Bu i\u015flemin ard\u0131ndan ise job’\u0131n silinme i\u015flemini ger\u00e7ekle\u015ftirebiliriz.<\/p>\n
\u00d6zetle<\/h2>\n
Kubernetes jobs, di\u011fer pod controller’lar\u0131ndan farkl\u0131 olarak bizlere tek seferlik i\u015flemlerimizi \u00e7al\u0131\u015ft\u0131rabilece\u011fimiz bir yap\u0131 sa\u011flamaktad\u0131r. Bizde bu yap\u0131 ile migration gibi i\u015flemlerimizi nas\u0131l ger\u00e7ekle\u015ftirebilece\u011fimize basit\u00e7e bakmaya \u00e7al\u0131\u015ft\u0131k.<\/p>\n
E\u011fer migration uygulamas\u0131n\u0131 ana uygulamadan ba\u011f\u0131ms\u0131z olarak deploy etmiyor olsayd\u0131k, bir ba\u015fka de\u011fi\u015fle ana uygulamam\u0131z\u0131n deployment an\u0131nda migration i\u015flemlerini de ger\u00e7ekle\u015ftirmek isteseydik, init container<\/strong> veya helm hook<\/strong> y\u00f6ntemlerini de kullan\u0131m senaryolar\u0131na g\u00f6re tercih edebilirdik.<\/p>\nBunlar\u0131n yan\u0131 s\u0131ra job’lar\u0131n, farkl\u0131 kullan\u0131m senaryolar\u0131 ve \u00f6zellikleri de mevcuttur. \u00d6rne\u011fin bir job’\u0131n execution time’\u0131n\u0131 “activeDeadlineSeconds<\/em>” parametresi ile kontrol edebiliriz. Farkl\u0131 kullan\u0131m senaryolar\u0131 i\u00e7in job konsept’i hakk\u0131nda daha fazla bilgi edinebilmek ad\u0131na, buray\u0131<\/a><\/em> inceleyebilirsiniz.<\/p>\n","protected":false},"excerpt":{"rendered":"Teknolojinin s\u00fcrekli geli\u015fti\u011fi ve de\u011fi\u015fti\u011fi gibi, i\u00e7erisinde \u00e7al\u0131\u015ft\u0131\u011f\u0131m\u0131z uygulaman\u0131n database schema’s\u0131 da her yeni implemente etti\u011fimiz \u00f6zellik ile de\u011fi\u015febilmekte. Dolay\u0131s\u0131yla domain model’lerinde ger\u00e7ekle\u015ftirilecek olan de\u011fi\u015fikliklerin, database schema’s\u0131 \u00fczerinde de uygulanabilmesi i\u00e7in bir migration stratejisi izlememiz gerekmektedir. Bu makale kapsam\u0131nda ise uygulamalar\u0131m\u0131z\u0131 kubernetes ortam\u0131na deploy ederken,…<\/p>\n
Ben geli\u015ftirme ortam\u0131 olarak Docker Desktop’un Kubernetes \u00f6zelli\u011fini kullanaca\u011f\u0131m.<\/p>\n
\u00d6rnek Projeye G\u00f6z Atal\u0131m<\/h2>\n
\u00d6ncelikle migration i\u015flemleri i\u00e7in .NET 5<\/strong> ve EF Core<\/strong> kullanarak haz\u0131rlad\u0131\u011f\u0131m buradaki<\/strong><\/em><\/a>\u00a0 \u00f6rnek projeyi inceleyelim.<\/p>\n Migration i\u015flemlerini ana uygulamadan ayr\u0131 bir \u015fekilde ger\u00e7ekle\u015ftirebilmek i\u00e7in, “Todo.DbMigration<\/em>” ad\u0131nda bir console application olu\u015fturdum. \u0130\u00e7erisinde ise basit olarak “IDesignTimeDbContextFactory<\/em>” interface’ini, “Todo.Data<\/em>” library’sindeki “TodoDbContext<\/em>” i kullanarak implemente ettim.<\/p>\n “Todo.Data<\/em>” library’sindeki db context ise a\u015fa\u011f\u0131daki gibidir.<\/p>\n Initial migration’\u0131 olu\u015fturabilmek i\u00e7in ise, projenin root klas\u00f6r\u00fcnde a\u015fa\u011f\u0131daki komutu \u00e7al\u0131\u015ft\u0131rd\u0131m.<\/p>\n Kubernetes jobs, bize sonlu i\u015flemlerimizi \u00e7al\u0131\u015ft\u0131rabilece\u011fimiz bir yap\u0131 sunmaktad\u0131r. T\u0131pk\u0131 bir controller’\u0131n fail olmu\u015f bir pod’u “reschedule” veya “restrart” etti\u011fi gibi, kubernetes jobs da sonlu olan i\u015flemlerimizin ba\u015far\u0131yla \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flamaktad\u0131r.<\/p>\n Kubernetes jobs ile olu\u015fturulan bir pod e\u011fer fail olmad\u0131 ve ba\u015far\u0131yla exit oldu ise, ilgili job ba\u015far\u0131yla tamamlanm\u0131\u015f olarak kabul edilmektedir. Bu i\u015flemi ise deploy etti\u011fimiz bir job’\u0131n “completion” durumunu sorgulayarak ger\u00e7ekle\u015ftirebiliriz.<\/p>\n Ayr\u0131ca bir job silindi\u011finde ise olu\u015fturmu\u015f oldu\u011fu pod’lar da otomatik olarak silinmektedir. Fakat job tamamland\u0131\u011f\u0131nda otomatik olarak silinmemektedir. Silinme i\u015flemi ise job’\u0131n completion durumu sorgulanarak, manuel olarak ger\u00e7ekle\u015ftirilmelidir. Bu i\u015fleme ise birazdan de\u011finece\u011fiz.<\/p>\n Toparlamak gerekirse kubernetes jobs, \u00f6zellikle batch veya migration gibi senaryolar i\u00e7in harika bir uyum sa\u011flamaktad\u0131r.<\/p>\n Ben deployment i\u015flemleri i\u00e7in productivity’i artt\u0131rd\u0131\u011f\u0131, tekrar kullan\u0131labilirli\u011fi sa\u011flad\u0131\u011f\u0131 ve bir standardizasyon kazand\u0131rd\u0131\u011f\u0131 i\u00e7in helm’i kullanmay\u0131 tercih ediyorum. Bu y\u00fczden job deployment i\u015flemi i\u00e7in de bir helm chart kullanaca\u011f\u0131z.<\/p>\n Bunun i\u00e7in \u00f6ncelikle bir job helm chart template’i olu\u015fturmam\u0131z gerekmektedir.<\/p>\n \u015eimdi projenin root klas\u00f6r\u00fcnde bulunan “helm-charts<\/em>” path’ine giderek, a\u015fa\u011f\u0131daki komut ile bir initial helm chart template’i olu\u015ftural\u0131m.<\/p>\n Ard\u0131ndan chart i\u00e7erisindeki “templates<\/em>” klas\u00f6r\u00fc i\u00e7erisinde bulunan “_helpers.tpl<\/em>” dosyas\u0131 hari\u00e7 geriye kalan t\u00fcm dosyalar\u0131 silelim.<\/p>\n \u015eimdi “templates<\/em>” klas\u00f6r\u00fc alt\u0131nda “job.yaml<\/em>” dosyas\u0131n\u0131 a\u015fa\u011f\u0131daki gibi tan\u0131mlayal\u0131m.<\/p>\n Bu spec’deki dikkate almam\u0131z gereken k\u0131s\u0131m restrartPolicy <\/strong>ve backoffLimit<\/strong> dir. Ben herhangi bir ba\u015far\u0131 veya hata durumlar\u0131nda migration gibi i\u015flemler i\u00e7in pod’un\/container’\u0131n tekrar ba\u015flat\u0131lmas\u0131n\u0131 istemedi\u011fimden dolay\u0131 bu policy’leri “0” ve “Never” olarak ayarl\u0131yorum. (Elbette baz\u0131 istisnai durumlar kar\u015f\u0131s\u0131nda bunun da garantisi yok) Aksi taktirde “backoffLimit” default olarak “6” oldu\u011fu i\u00e7in, job, hata veren pod’u tekrar ve tekrar ba\u015flatmay\u0131 deneyecektir.<\/p>\n Ayr\u0131ca bu configuration ile, o anki olu\u015fan hatan\u0131n neyden dolay\u0131 kaynakland\u0131\u011f\u0131n\u0131 bulabilmemiz de kolayla\u015facakt\u0131r.<\/p>\n Value dosyas\u0131n\u0131 ise a\u015fa\u011f\u0131daki gibi g\u00fcncelleyelim.<\/p>\n B\u00f6ylece helm chart template’i haz\u0131r durumda. \u015eimdi tek yapmam\u0131z gereken, \u00f6rnek projeyi “mytodoapp-migration:v1<\/em>” tag’i ile containerize bir hale getirmek.<\/p>\n “Todo.DbMigration<\/em>” projesi i\u00e7erisinde a\u015fa\u011f\u0131daki gibi bir Dockerfile<\/strong> bulunmaktad\u0131r.<\/p>\n \u015eimdi projenin root klas\u00f6r\u00fcnde a\u015fa\u011f\u0131daki komutu \u00e7al\u0131\u015ft\u0131rarak migration uygulamas\u0131n\u0131 containerize bir hale getirelim.<\/p>\n \u00d6rnek uygulamay\u0131 containerize bir hale getirdi\u011fimize g\u00f6re, deployment i\u015flemini ger\u00e7ekle\u015ftirebiliriz.<\/p>\n Bunun i\u00e7in projenin root klas\u00f6r\u00fcnde bulunan “helm-charts<\/em>” path’ine giderek, a\u015fa\u011f\u0131daki helm komutunu \u00e7al\u0131\u015ft\u0131ral\u0131m.<\/p>\n \u00d6rnek migration uygulamam\u0131z deploy olmu\u015f durumda.<\/p>\n \u00d6ncelikle a\u015fa\u011f\u0131daki komutu kullanarak job’\u0131n ba\u015far\u0131yla tamamlan\u0131p tamamlanmad\u0131\u011f\u0131n\u0131 kontrol edelim.<\/p>\n G\u00f6rd\u00fc\u011f\u00fcm\u00fcz gibi deploy etti\u011fimiz migration uygulamas\u0131n\u0131n “COMPLETIONS<\/em>” durumuna bakarak, ba\u015far\u0131yla tamamlan\u0131p tamamlanmad\u0131\u011f\u0131n\u0131 anlayabiliriz.<\/p>\n E\u011fer herhangi bir hata meydana gelseydi, job’\u0131n olu\u015fturdu\u011fu ilgili pod’un log’lar\u0131na bakarak ilgili hatan\u0131n izini de s\u00fcrebilirdik.<\/p>\n Migration sonucunu SQL Server’a ba\u011flanarak kontrol etti\u011fimizde ise, ilgili migration’\u0131n ba\u015far\u0131yla uyguland\u0131\u011f\u0131n\u0131 g\u00f6rebiliriz.<\/p>\n Ayr\u0131ca bir job’\u0131n tamamland\u0131\u011f\u0131nda otomatik olarak silinmedi\u011finden de bahsetmi\u015ftik. Silme i\u015flemini ger\u00e7ekle\u015ftirmek i\u00e7in ise, a\u015fa\u011f\u0131daki standart helm komutunu kullanabiliriz.<\/p>\n Peki diyelim ki biz bu i\u015flemleri automated bir hale getirmek istiyoruz. \u00d6rne\u011fin Azure DevOps<\/strong> kullan\u0131yoruz ve ilgili migration job’\u0131n\u0131n, ba\u015far\u0131yla tamamlanmas\u0131ndan sonra otomatik olarak silinmesini istiyoruz.<\/p>\n Bu i\u015flemi ger\u00e7ekle\u015ftirebilmek i\u00e7in ise, “kubectl<\/em>” in “wait<\/em>” komutundan yararlanabiliriz. Bir ba\u015fka de\u011fi\u015fle ilgili job’\u0131 silmeden \u00f6nce, bekleme i\u015flemini job tamamlanana kadar s\u00fcrd\u00fcrmemiz gerekmektedir.<\/p>\n Bunu ise a\u015fa\u011f\u0131daki komut yard\u0131m\u0131 ile yapabiliriz.<\/p>\n G\u00f6rd\u00fc\u011f\u00fcm\u00fcz gibi belirtti\u011fimiz condition ger\u00e7ekle\u015fene kadar ilgili task, timeout s\u00fcresi boyunca bekletilecektir. Bu i\u015flemin ard\u0131ndan ise job’\u0131n silinme i\u015flemini ger\u00e7ekle\u015ftirebiliriz.<\/p>\n Kubernetes jobs, di\u011fer pod controller’lar\u0131ndan farkl\u0131 olarak bizlere tek seferlik i\u015flemlerimizi \u00e7al\u0131\u015ft\u0131rabilece\u011fimiz bir yap\u0131 sa\u011flamaktad\u0131r. Bizde bu yap\u0131 ile migration gibi i\u015flemlerimizi nas\u0131l ger\u00e7ekle\u015ftirebilece\u011fimize basit\u00e7e bakmaya \u00e7al\u0131\u015ft\u0131k.<\/p>\n E\u011fer migration uygulamas\u0131n\u0131 ana uygulamadan ba\u011f\u0131ms\u0131z olarak deploy etmiyor olsayd\u0131k, bir ba\u015fka de\u011fi\u015fle ana uygulamam\u0131z\u0131n deployment an\u0131nda migration i\u015flemlerini de ger\u00e7ekle\u015ftirmek isteseydik, init container<\/strong> veya helm hook<\/strong> y\u00f6ntemlerini de kullan\u0131m senaryolar\u0131na g\u00f6re tercih edebilirdik.<\/p>\n Bunlar\u0131n yan\u0131 s\u0131ra job’lar\u0131n, farkl\u0131 kullan\u0131m senaryolar\u0131 ve \u00f6zellikleri de mevcuttur. \u00d6rne\u011fin bir job’\u0131n execution time’\u0131n\u0131 “activeDeadlineSeconds<\/em>” parametresi ile kontrol edebiliriz. Farkl\u0131 kullan\u0131m senaryolar\u0131 i\u00e7in job konsept’i hakk\u0131nda daha fazla bilgi edinebilmek ad\u0131na, buray\u0131<\/a><\/em> inceleyebilirsiniz.<\/p>\n","protected":false},"excerpt":{"rendered":" Teknolojinin s\u00fcrekli geli\u015fti\u011fi ve de\u011fi\u015fti\u011fi gibi, i\u00e7erisinde \u00e7al\u0131\u015ft\u0131\u011f\u0131m\u0131z uygulaman\u0131n database schema’s\u0131 da her yeni implemente etti\u011fimiz \u00f6zellik ile de\u011fi\u015febilmekte. Dolay\u0131s\u0131yla domain model’lerinde ger\u00e7ekle\u015ftirilecek olan de\u011fi\u015fikliklerin, database schema’s\u0131 \u00fczerinde de uygulanabilmesi i\u00e7in bir migration stratejisi izlememiz gerekmektedir. Bu makale kapsam\u0131nda ise uygulamalar\u0131m\u0131z\u0131 kubernetes ortam\u0131na deploy ederken,…<\/p>\nusing System.IO;\r\nusing Microsoft.EntityFrameworkCore;\r\nusing Microsoft.EntityFrameworkCore.Design;\r\nusing Microsoft.Extensions.Configuration;\r\nusing Todo.Data;\r\n\r\nnamespace Todo.DbMigration\r\n{\r\n public class TodoDbContextFactory : IDesignTimeDbContextFactory<TodoDbContext>\r\n {\r\n public TodoDbContext CreateDbContext(string[] args)\r\n {\r\n var configuration = new ConfigurationBuilder()\r\n .SetBasePath(Directory.GetCurrentDirectory())\r\n .AddJsonFile(\"appsettings.json\")\r\n .AddEnvironmentVariables()\r\n .Build();\r\n\r\n var dbContextOptionsBuilder = new DbContextOptionsBuilder<TodoDbContext>();\r\n \r\n var connectionString = configuration\r\n .GetConnectionString(\"SqlConnectionString\");\r\n \r\n dbContextOptionsBuilder.UseSqlServer(connectionString, x => x.MigrationsAssembly(\"Todo.DbMigration\"));\r\n \r\n return new TodoDbContext(dbContextOptionsBuilder.Options);\r\n }\r\n }\r\n}<\/pre>\n<\/div>\nusing Microsoft.EntityFrameworkCore;\r\nusing Todo.Data.Models;\r\n\r\nnamespace Todo.Data\r\n{\r\n public class TodoDbContext : DbContext\r\n {\r\n public TodoDbContext(DbContextOptions<TodoDbContext> options)\r\n : base(options)\r\n {\r\n\r\n }\r\n\r\n public DbSet<TodoEntity> Todos { get; set; }\r\n\r\n protected override void OnModelCreating(ModelBuilder modelBuilder)\r\n {\r\n modelBuilder.Entity<TodoEntity>()\r\n .HasKey(x => x.Id);\r\n modelBuilder.Entity<TodoEntity>()\r\n .Property(p => p.Name)\r\n .HasMaxLength(150)\r\n .IsRequired();\r\n }\r\n }\r\n}<\/pre>\n<\/div>\ndotnet ef migrations add InitialCreate --project .\/Todo.Migration<\/pre>\n<\/div>\n
![\"\"](\"\/wp-content\/uploads\/2021\/03\/create-initial-migration.jpg\")
<\/a><\/p>\nKubernetes Jobs<\/h2>\n
Job Helm Chart Template’i Olu\u015ftural\u0131m<\/h3>\n
helm create migration-job<\/pre>\n<\/div>\n
apiVersion: batch\/v1\r\nkind: Job\r\nmetadata:\r\n name: {{ include \"migration-job.fullname\" . }}\r\nspec:\r\n backoffLimit: 0\r\n template:\r\n spec:\r\n containers:\r\n - name: {{ .Chart.Name }}\r\n image: \"{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}\"\r\n restartPolicy: Never\r\n {{- with .Values.nodeSelector }}\r\n nodeSelector:\r\n {{- toYaml . | nindent 8 }}\r\n {{- end }}<\/pre>\n<\/div>\nimage:\r\n repository: mytodoapp-migration\r\n tag: \"v1\"\r\n\r\nnodeSelector:\r\n beta.kubernetes.io\/os: linux<\/pre>\n<\/div>\n
Containerize Edelim<\/h2>\n
FROM mcr.microsoft.com\/dotnet\/runtime:5.0 AS base\r\nWORKDIR \/app\r\n\r\nFROM mcr.microsoft.com\/dotnet\/sdk:5.0 AS build\r\nWORKDIR \/src\r\nCOPY [\"Todo.DbMigration\/Todo.DbMigration.csproj\", \"Todo.DbMigration\/\"]\r\nRUN dotnet restore \"Todo.DbMigration\/Todo.DbMigration.csproj\"\r\nCOPY . .\r\nWORKDIR \"\/src\/Todo.DbMigration\"\r\nRUN dotnet build \"Todo.DbMigration.csproj\" -c Release -o \/app\/build\r\n\r\nFROM build AS publish\r\nRUN dotnet publish \"Todo.DbMigration.csproj\" -c Release -o \/app\/publish\r\n\r\nFROM base AS final\r\nWORKDIR \/app\r\nCOPY --from=publish \/app\/publish .\r\nENTRYPOINT [\"dotnet\", \"Todo.DbMigration.dll\"]<\/pre>\n<\/div>\n
docker build -f .\/Todo.DbMigration\/Dockerfile . -t mytodoapp-migration:v1<\/pre>\n<\/div>\n
![\"\"](\"\/wp-content\/uploads\/2021\/03\/containerize-migration.jpg\")
<\/a><\/p>\n<\/h2>\n
Deploy Edelim<\/h2>\n
helm upgrade --install --values .\/migration-job\/values.yaml mytodo-migration .\/migration-job<\/pre>\n<\/div>\n
![\"\"](\"\/wp-content\/uploads\/2021\/04\/helm-install-job.jpg\")
<\/a><\/p>\nPeki \u015fimdi neler yapabiliriz?<\/h3>\n
kubectl get job<\/pre>\n<\/div>\n
![\"\"](\"\/wp-content\/uploads\/2021\/04\/kubectl-get-job.jpg\")
<\/a><\/p>\n![\"\"](\"\/wp-content\/uploads\/2021\/04\/sql-migration-result.jpg\")
<\/a><\/p>\nhelm delete mytodo-migration<\/pre>\n<\/div>\n
kubectl wait --for-condition=complete job\/mytodo-migration-migration-job --timeout=2m<\/pre>\n<\/div>\n
![\"\"](\"\/wp-content\/uploads\/2021\/04\/kubectl-job-wait-condition.jpg\")
<\/a><\/p>\n![\"\"](\"\/wp-content\/uploads\/2021\/04\/wait-devops.jpg\")
<\/a><\/p>\n\u00d6zetle<\/h2>\n