CodeDays 2019, München: 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.

1. Alex Krause
alex.krause@qaware.de
@alex0ptr
Cron in der Cloud
Die Top 10 Hitparade

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. 45 6 * * *
generateReport.sh !
Instance PostgreSQL
instance

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. Probleme 💣
1. Scheduling
2. Leader Election
@alex0ptr

6. Die Top 10 Hitparade für
Cloud-Natives Cron
@alex0ptr
🎊

7. 🔍 Kriterien
1. Anforderungen Applikation
2. Deployment/Integration
3. Robustheit
4. Monitoring
@alex0ptr

8. #10: wir haben keine Zeit,
das lassen wir machen…
@alex0ptr
💸

9. @alex0ptr

10. @alex0ptr

11. @alex0ptr

12. Anforderungen
Applikation 😁
Deployment /
Integration 😱
Robustheit
🙂
Monitoring
😕
@alex0ptr
Nicht nachm
achen!

13. #9: da hinten ist noch so
eine Kiste…
@alex0ptr
🧟

14. @alex0ptr

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. Anforderungen
Applikation 😁
Deployment /
Integration 😬
Robustheit
😕
Monitoring
😕
@alex0ptr
Nicht nachm
achen!

17. #8: das haben wir schon
immer so gemacht…
@alex0ptr
🧐

18. @alex0ptr
45 6 * * *
generateReport.sh
!

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. Anforderungen
Applikation 😁
Deployment /
Integration 🙂
Robustheit
😕
Monitoring
😕
@alex0ptr
Nicht nachm
achen!

21. 🧐
#7: das haben wir schon
immer so gemacht #2…
@alex0ptr
☕

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. Cluster Support
@alex0ptr
“Clustering currently works with the JDBC-Jobstore […]
and the TerracottaJobStore.”

24. Anforderungen
Applikation 😕
Deployment /
Integration 😐
Robustheit
😁
Monitoring
😕
@alex0ptr

25. #6: ok, dann machen wir
das halt selbst…
@alex0ptr
0

26. 1 Zutaten
1. Scheduler (z.B. cron, Quartz)
2. Verteilter Lock (z.B. etcd,
Hazelcast, Redis)
3. Viel Arbeit
@alex0ptr

27. 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

28. Anforderungen
Applikation 😁
Deployment /
Integration 🙁
Robustheit
🤔
Monitoring
🤔
@alex0ptr

29. #5: unsere Jobs sind
Rechenintensiv…
@alex0ptr
💪

30. Type: AWS::AutoScaling::ScheduledAction
Properties:
AutoScalingGroupName: recalc-world-cron-group
DesiredCapacity: 1
Recurrence: 45 6 * * *
Auto Scaling Group

31. Type: AWS::AutoScaling::ScheduledAction
Properties:
AutoScalingGroupName: recalc-world-cron-group
DesiredCapacity: 1
Recurrence: 45 6 * * *
Auto Scaling GroupAuto Scaling Group
InstanceRole
assume
autoscaling:DetachInstances

32. Auto Scaling Group
Instance
#!/bin/bash
…

33. #!/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

34. Anforderungen
Applikation 😁
Deployment /
Integration 🙂
Robustheit
😕
Monitoring
😕
@alex0ptr

35. #4: 100% Cloud:
Serverless Architektur…
@alex0ptr
☁

36. Lambda Function
Amazon
CloudWatch
Event
45 6 * * *

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. Anforderungen
Applikation 😄
Deployment /
Integration 😄
Robustheit
😕
Monitoring
🙂
@alex0ptr

40. #3: hat jemand Kubernetes
gesagt?
@alex0ptr

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. increase(kube_job_status_failed{job=~"cronjob-.*"}[5m]) > 1
https://github.com/kubernetes/kube-state-metrics

43. Anforderungen
Applikation 😄
Deployment /
Integration 😄
Robustheit
😕
Monitoring
🙂
@alex0ptr

44. #2: ich bin in der Google
Cloud…
@alex0ptr
😌

45. @alex0ptr

46. @alex0ptr

47. @alex0ptr

48. Anforderungen
Applikation 😄
Deployment /
Integration 🙂
Robustheit
😄
Monitoring
😄
@alex0ptr

49. #1: das muss doch besser
gehen: K8s Operator
@alex0ptr
😎

50. Kubernetes Operator
@alex0ptr
„Custom Resources + Controller = ❤“

51. krondor
‣ Drop-In Lösung
‣ HTTP Integration
‣ Kubernetes (first)
‣ Eingebautes Monitoring
‣ At-least-once
‣ Retries mit Back-Off
@alex0ptr

52. 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

53. 🎊 Demo 🎉
@alex0ptr

54. Anforderungen
Applikation 😄
Deployment /
Integration 😄
Robustheit
😄
Monitoring
😄
@alex0ptr

55. 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

56. QAware21.09.2018 56

57. 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

58. 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