Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Cron in der Cloud - Die Top 10 Hitparade

194 views

Published on

IT-Tage 2018, Frankfurt: Vortrag von Alex Krause (@alex0ptr, Senior Softwareingenieur bei QAware)

=== Dokument bitte herunterladen, falls unscharf! Please download slides if blurred! ===

Abstract:
Die meisten Backend-Systeme führen neben den kontinuierlich laufenden Prozessen, die einen Web-Service ausmachen, auch zeitlich gesteuerte Prozesse durch. Diese sind notwendig, um zu regelmäßigen Zeitpunkten Reports zu generieren, Housekeeping und Backups durchzuführen, E-Mails zu versenden oder Caches neu aufzubauen. Der bekannte Cron-Daemon automatisiert solche Prozesse schon fast seit Anbeginn der Computer-Ära. Beim Versuch, dieses Tool auf die von Microservices, Cloud und Container getriebene Welt anzuwenden, stellen sich jedoch Fragen: Wie kann ich meine Cron-Prozesse auf mehrere Instanzen verteilen? Wie garantiere ich die Ausführung des Tasks, wenn mein Container jederzeit heruntergefahren und ausgetauscht werden kann? Wie gestalte ich eine rollierende Ausführung über Container hinweg oder garantiere das ein Task nur einmal pro Zeiteinheit in meinem Cluster ausgeführt wird?

Um diese Fragen zu beantworten und für jeden das richtige Tool zu finden, schauen wir uns in diesem Talk zehn verschiedene Optionen für Cloud-Nnatives Cron an. Hierbei bedienen wir uns unter anderem bei Frameworks, Microservices, AWS Cloud-Infrastruktur, Serverless-Komponenten, Container-Orchestrierung und einem Kubernetes-Operator. Nebenbei bewerten wir, ganz subjektiv, die Cloud-nativeness, die Flexibilität der Lösung sowie den Aufwand bei Integration und Monitoring.

Published in: Data & Analytics
  • Be the first to comment

Cron in der Cloud - Die Top 10 Hitparade

  1. 1. 10. – 13.12.2018 Frankfurt am Main #ittage Cron in der Cloud Die Top 10-Hitparade Alex Krause @alex0ptr @alex0ptr
  2. 2. „Jeden Tag um 06:45 Uhr berechnet der Service aus dem aktuellen Datenbestand die Menge der reservierten Kontingente. Der resultierende Report soll persistiert und per eMail an den Fachbereich gesendet werden.“ @alex0ptr
  3. 3. 45 6 * * * generateReport.sh ! Instance PostgreSQL instance
  4. 4. @alex0ptr Availability zone VPC Subnet Availability zone Subnet Subnet Auto Scaling Group Subnet Instances Instances DB instance DB instance standby Application Load Balancer NAT gateway NAT gateway Application Load Balancer 😨
  5. 5. Probleme 💣 1. Scheduling 2. Leader Election 3. Koordination @alex0ptr
  6. 6. Die Top 10 Hitparade für Cloud-Natives Cron @alex0ptr 🎊
  7. 7. 🔍 Kriterien 1. Anforderungen Applikation 2. Deployment/Integration 3. Robustheit 4. Monitoring @alex0ptr
  8. 8. #10: wir haben keine Zeit, das lassen wir machen… @alex0ptr 💸
  9. 9. @alex0ptr
  10. 10. @alex0ptr
  11. 11. @alex0ptr
  12. 12. Anforderungen Applikation 😁 Deployment / Integration 😱 Robustheit 🙂 Monitoring 😕 @alex0ptr Nicht nachm achen!
  13. 13. #9: da hinten ist noch so eine Kiste… @alex0ptr 🧟
  14. 14. @alex0ptr
  15. 15. @alex0ptr https://medium.freecodecamp.org/56-seconds-to-get-gitlab-to-do-periodic-jobs-for-you-6a731b977559 test: script: - btc=$(curl https://min- api.cryptocompare.com/data/price? fsym=BTC&tsyms=CAD) - curl -i -X POST https://putsreq.com/ wkDdMQWhaOyalisaIe49 — data ‘price=CA$ ‘“$ {btc//[0-9.]/}”
  16. 16. Anforderungen Applikation 😁 Deployment / Integration 😬 Robustheit 😕 Monitoring 😕 @alex0ptr Nicht nachm achen!
  17. 17. #8: das haben wir schon immer so gemacht… @alex0ptr 🧐
  18. 18. @alex0ptr 45 6 * * * generateReport.sh !
  19. 19. @alex0ptr FROM alpine RUN apk add --no-cache curl CMD ["sh", "-c", "crontab /etc/cron/crontab; crond -f -d 8"] --- apiVersion: apps/v1 kind: Deployment […] spec: […] spec: containers: - name: cron image: cron imagePullPolicy: IfNotPresent volumeMounts: - name: config mountPath: /etc/cron/ volumes: - name: config configMap: name: crontab --- apiVersion: v1 kind: ConfigMap metadata: name: crontab data: crontab: | */1 * * * * curl myservice.local/job/crontainer
  20. 20. Anforderungen Applikation 😁 Deployment / Integration 🙂 Robustheit 😕 Monitoring 😕 @alex0ptr Nicht nachm achen!
  21. 21. #7: das haben wir schon immer so gemacht #2… @alex0ptr . 🎩
  22. 22. @alex0ptr // define the job and tie it to our MyJob class JobDetail job = newJob(MyJob.class) .withIdentity("job1", "group1") .build(); // Trigger the job to run now, and then repeat every 40 seconds Trigger trigger = newTrigger() .withIdentity("trigger1", "group1") .startNow() .withSchedule(simpleSchedule() .withIntervalInSeconds(40) .repeatForever()) .build(); // Tell quartz to schedule the job using our trigger scheduler.scheduleJob(job, trigger);
  23. 23. Cluster Support @alex0ptr “Clustering currently works with the JDBC-Jobstore […] and the TerracottaJobStore.”
  24. 24. Anforderungen Applikation 😕 Deployment / Integration 😐 Robustheit 😁 Monitoring 😕 @alex0ptr
  25. 25. #6: ok, dann machen wir das halt selbst… @alex0ptr 1
  26. 26. 2 Zutaten 1. Scheduler (z.B. cron, Quartz) 2. Verteilter Lock (z.B. etcd, Hazelcast, Redis) 3. Viel Arbeit @alex0ptr
  27. 27. Golang + Postgres https://github.com/rafaeljesus/crony “Crony works by calling back to your application via HTTP GET according to a schedule constructed by you or your application.”
  28. 28. Bash + Redis = http://github.com/kvz/cronlock “Uses a central Redis server to globally lock cronjobs across a distributed system. This can be usefull if you have 30 webservers that you deploy crontabs to (such as mailing your customers), but you don't want 30 cronjobs spawned.” echo '0 8 * * * CRONLOCK_HOST=redis.mydomain.com cronlock /var/www/mail_customers.sh' | crontab
  29. 29. Anforderungen Applikation 😁 Deployment / Integration 🙁 Robustheit 🤔 Monitoring 🤔 @alex0ptr
  30. 30. #5: unsere Jobs sind Rechenintensiv… @alex0ptr 💪
  31. 31. Type: AWS::AutoScaling::ScheduledAction Properties: AutoScalingGroupName: recalc-world-cron-group DesiredCapacity: 1 Recurrence: 45 6 * * * Auto Scaling Group
  32. 32. Type: AWS::AutoScaling::ScheduledAction Properties: AutoScalingGroupName: recalc-world-cron-group DesiredCapacity: 1 Recurrence: 45 6 * * * Auto Scaling GroupAuto Scaling Group InstanceRole assume autoscaling:DetachInstances
  33. 33. Auto Scaling Group Instance #!/bin/bash …
  34. 34. #!/bin/bash set -e set -u set -o pipefail function finish { shutdown -h now } trap finish EXIT aws autoscaling detach-instances --instance-ids $(curl http://169.254.169.254/latest/meta-data/instance-id) --auto-scaling-group-name recalc-world-cron-group --should-decrement-desired-capacity . ./expensive-task.sh
  35. 35. Anforderungen Applikation 😁 Deployment / Integration 🙂 Robustheit 😕 Monitoring 😕 @alex0ptr
  36. 36. #4: 100% Cloud: Serverless Architektur… @alex0ptr ☁
  37. 37. Lambda Function Amazon CloudWatch Event 45 6 * * *
  38. 38. service: cron-serverless provider: name: aws runtime: java8 package: artifact: target/cron-dev.jar functions: cron: handler: com.serverless.Handler events: - schedule: rate(1 minutes)
  39. 39. Anforderungen Applikation 😄 Deployment / Integration 😄 Robustheit 😕 Monitoring 🙂 @alex0ptr
  40. 40. #3: hat jemand Kubernetes gesagt? @alex0ptr
  41. 41. --- apiVersion: batch/v2alpha1 kind: CronJob metadata: name: scheduled-job spec: schedule: "*/20 * * * *" jobTemplate: spec: template: metadata: labels: parent: "scheduled-kill-core" spec: serviceAccountName: scheduled-kill-core containers: - name: scheduled-kill-core image: widerin/openshift-cli command: ["/bin/sh"] args: - "-c" - > oc patch deployment core -p "{[…]}" restartPolicy: Never
  42. 42. increase(kube_job_status_failed{job=~"cronjob-.*"}[5m]) > 1 https://github.com/kubernetes/kube-state-metrics
  43. 43. Anforderungen Applikation 😄 Deployment / Integration 😄 Robustheit 😕 Monitoring 🙂 @alex0ptr
  44. 44. #2: ich bin in der Google Cloud… @alex0ptr 😌
  45. 45. @alex0ptr
  46. 46. @alex0ptr
  47. 47. @alex0ptr
  48. 48. Anforderungen Applikation 😄 Deployment / Integration 🙂 Robustheit 😄 Monitoring 😄 @alex0ptr
  49. 49. #1: das muss doch besser gehen: K8s Operator @alex0ptr 😎
  50. 50. krondor ‣ Drop-In Lösung ‣ HTTP Integration ‣ Kubernetes (first) ‣ Eingebautes Monitoring ‣ At-least-once ‣ Retries mit Back-Off @alex0ptr
  51. 51. CRD PodPod PodPod krondor # krongroup reservations - - - name: reservations selector: matchLabels: app: http-container jobs: - name: release-unpaid-seats endpoint: [...] schedule: PT1M - name: mail-stakeholders endpoint: [...] [...] 1. reads 2. discover reservations 3. http call
  52. 52. 🎊 Demo 🎉 @alex0ptr
  53. 53. Anforderungen Applikation 😄 Deployment / Integration 😄 Robustheit 😄 Monitoring 😄 @alex0ptr
  54. 54. xing.com/companies/qawaregmbh linkedin.com/company/qaware-gmbh slideshare.net/qaware twitter.com/qaware github.com/qaware youtube.com/qawaregmbh Alex Krause alex.krause@qaware.de @alex0ptr
  55. 55. QAware21.09.2018 56
  56. 56. QAware GmbH Mainz Rheinstraße 4 D 55116 Mainz Tel.: +49 (0) 6131 215 69 – 0 Fax: +49 (0) 6131 215 69 – 68 xing.com/companies/qawaregmbh linkedin.com/company/qaware-gmbh slideshare.net/qaware twitter.com/qaware github.com/qaware youtube.com/qawaregmbh
  57. 57. QAware GmbH München Aschauer Straße 32 81549 München Tel.: +49 (0) 89 23 23 15 – 0 Fax: +49 (0) 89 23 23 15 – 129 xing.com/companies/qawaregmbh linkedin.com/company/qaware-gmbh slideshare.net/qaware twitter.com/qaware github.com/qaware youtube.com/qawaregmbh

×