Successfully reported this slideshow.

Deep-dive into cloud-native AEM deployments based on Kubernetes

1

Share

1 of 36
1 of 36

Deep-dive into cloud-native AEM deployments based on Kubernetes

1

Share

Download to read offline

Description

AEM instance is traditionally see as a "pet" - an application that requires manual work for the deployment and the constant oversee in the runtime. Transforming instances into "cattle" and moving them into cloud brings a number of challenges around persistence, replication, scaling, monitoring, upgrades and maintenance. However, cloud computing services like Azure and container orchestration systems like Kubernetes allows to solve these problems in the new, creative ways, while the resulting cloud setup offers scalability not possible before.

This session will provide an overview on the Kubernetes setup we internally use in Adobe, the issues we've run into and the ways we're dealing with them.

Transcript

  1. 1. APACHE SLING&FRIENDSTECHMEETUP 2- 4SEPTEMBER 2019 Deep-diveinto cloud-native AEM deployments based on Kubernetes Tomek Rękawek, Adobe
  2. 2. 2 Cloud: whatand why?
  3. 3. Wewanttomovefrom 3
  4. 4. to 4
  5. 5. Cloud:why? 5  RunningAEM at scale  Hassle-freedeployments  The cloud provider (AWS, Azure) should worry about infrastructure
  6. 6. Agenda 6  Jobs  Content migration  New indexes  QA  Docker&Kubernetesintroduction  Architectureoverview  Publishpersistence  Cloud Segment Store  Golden publish  Compaction  Sidecarservices
  7. 7. 7 Docker & Kubernetesintroduction
  8. 8. Thepowerofstandardization 8
  9. 9. DockerizedAEM 9  AEM in Docker image  Composite Node Store  /apps& /libs storedin thecontainer  Actualcontentlives outside,in the VOLUMEorMongoDB  OSGi Feature Model  DefinesAEMandcustomerapplication  Featurelauncherstartsit inside container  Covered in Karl& David’spresentation  SeeadaptTo() 2017 talk for moredetails
  10. 10. Mini intro toKubernetes 10  Launches Docker containers without worrying about the underlying VMs  Dictionary  Pod–a groupofcontainersstartingtogetheron asingle machine  Service –internalloadbalancer,exposinganumberofpodreplicas underasingle address  Ingress– exposesa service underanpublic httpaddress  Everyentity is represented by a YAML object in K8s API server  TheYAML is the desired state, K8s knows how to get there
  11. 11. DeploymentswithHelm 11  Helm – K8s apps management  Chart – a bunch of K8s YAML descriptors, with a simple templating  Whole AEMdeployment canbe installed/upgraded with a single command Image:https://helm.sh
  12. 12. 12 Architecture overview
  13. 13. AEMKubernetessetup 13
  14. 14. 14 Publishpersistence evolution
  15. 15. Problemdefinition 15  Author persistence is easy-ish with MongoDB  Publish is harder –local SegmentMK, no clustering  Thepublish farm is kept up-to-date with replication  However:  weneed toprovidethenew publishinstanceswitha segment store,  copyit fromanotherinstance.  Problems:  copyingfiles betweenpodsis hardandhacky,  whatif there’snopublishto copyfrom?
  16. 16. Cloud SegmentStore 16  A new plugin for the Segment Node Store  Nodes are stored in a cloud storage service  No tar files, raw segments grouped in dirs  Can be used in RW or RO modes
  17. 17. Goldenpublish 17  A designated publish instance  Not connectedto LB  It maintainsa “golden copy” of the segmentstore  New publish just clone it
  18. 18. Problem:duplicatedbinaries andstartuptime 18 Golden publish Segment 1 Segment 2 Segment 4 Segment 3 Segment x Publish 1 Segment 1 Segment 2 Segment 4 Segment 3 Segment y Publish 2 Segment 1 Segment 2 Segment 4 Segment 3 Segment z Publish 3 (starting) Segment 1 Segment 2 Segment 3 Segment 4  Multiple copies of the same segments 1-4 ($$$)  Cloning a bucket takes time during the publish start ( 🕑🕑🕑)
  19. 19. Optimization:a singlesegmentstore 19
  20. 20. 20 Publishpersistence: compaction
  21. 21. Compaction 21
  22. 22. Out-of-bandpublish update 22  This pattern willbe usefulin many cases  We may clone thepublish repository, modify it and re-deploy instanceson top of it  Persisted message queuewill apply missingchanges
  23. 23. 23 Sidecar services
  24. 24. Sidecar approach 24  A single pod can run many containers, sharing their volumes and localhost interface  We can use them for the auxiliaryservices (sidecars):  Dispatcher in the publish pod  Upload logs to Splunk  Warmup service
  25. 25. AEMpod withsidecars 25Sidecaricon: Flaticons.com
  26. 26. 26 Jobs
  27. 27. Kubernetesjob 27  Starts a pod  Meantto perform a specific task and finish  Unlikethe deployment, which run indefinitely  Willbe restarted if fails  Jobs provides a way to interactwiththe deployed AEM
  28. 28. 28 Contentmigration
  29. 29. Contentmigration 29  How to migrate old content to K8s?  Access problem  old AEM envs shouldn’t have access to the K8s (encapsulation)  K8s shouldn’t be able to access oldAEMs (they can be installed anywhere)  Solution:demilitarized zone
  30. 30. 2-phasemigration 30  Phase 1  Themigrator tool (crx2oak-like jar) is used to export old AEM content into a cloud storage service  Phase 2  A Kubernetes job is used to apply the migrated content on the cloud instances
  31. 31. 31 Newindexes
  32. 32. Addingnew index 32  Indexesaretricky  /oak:index is a part of the mutable content  But indexdefinitions belongs to the application  Onlyaddingnew indexesis supported  Whena new indexis addedin /oak:index,it’ll haveanextra useIfExistspropertyreferencing immutable part/apps  This bounds the index definition tothe application version andDocker image  This /appspathhaveto beaddedas well • /oak:index/my-new-index • useIfExists: /apps/indexes@v3 • /apps/indexes • v3: true Mutable part Immutable part
  33. 33. Mutablecontent:addingnew index 33  Indexingjob should be runbefore the actual app deployment  Thejob will: 1. Look forthe new index defs in /oak:index 2. Perform out of band indexing ofthe content 3. Save the new indexing content tothe production repository  TheuseIfExists will makesure that the newindexis ignored, untilthe newimageis installed  When the new image is deployed, the /apps part will be updated and the new index will beused
  34. 34. 34 Other topics
  35. 35. Relatedtopics 35  Feature model usage in Docker (covered in David’s and Karl’stalk)  Replication (covered in Timothee’s talk)  Monitoring with Prometheus and Grafana  CI/CD pipeline  Network policies  …
  36. 36. 36 Thanks!

Editor's Notes

  • Hello! My name is Tomek Rękawek, I work for Adobe.

    In this presentation I‘ll tell you abou the cloud setup for AEM that we‘re workin on.

    I won‘t be able to cover any dates, licensing or prices,

    but I‘ll show as many technical details as possible, so I hope you‘ll enjoy it.
  • Description

    AEM instance is traditionally see as a "pet" - an application that requires manual work for the deployment and the constant oversee in the runtime. Transforming instances into "cattle" and moving them into cloud brings a number of challenges around persistence, replication, scaling, monitoring, upgrades and maintenance. However, cloud computing services like Azure and container orchestration systems like Kubernetes allows to solve these problems in the new, creative ways, while the resulting cloud setup offers scalability not possible before.

    This session will provide an overview on the Kubernetes setup we internally use in Adobe, the issues we've run into and the ways we're dealing with them.

    Transcript

    1. 1. APACHE SLING&FRIENDSTECHMEETUP 2- 4SEPTEMBER 2019 Deep-diveinto cloud-native AEM deployments based on Kubernetes Tomek Rękawek, Adobe
    2. 2. 2 Cloud: whatand why?
    3. 3. Wewanttomovefrom 3
    4. 4. to 4
    5. 5. Cloud:why? 5  RunningAEM at scale  Hassle-freedeployments  The cloud provider (AWS, Azure) should worry about infrastructure
    6. 6. Agenda 6  Jobs  Content migration  New indexes  QA  Docker&Kubernetesintroduction  Architectureoverview  Publishpersistence  Cloud Segment Store  Golden publish  Compaction  Sidecarservices
    7. 7. 7 Docker & Kubernetesintroduction
    8. 8. Thepowerofstandardization 8
    9. 9. DockerizedAEM 9  AEM in Docker image  Composite Node Store  /apps& /libs storedin thecontainer  Actualcontentlives outside,in the VOLUMEorMongoDB  OSGi Feature Model  DefinesAEMandcustomerapplication  Featurelauncherstartsit inside container  Covered in Karl& David’spresentation  SeeadaptTo() 2017 talk for moredetails
    10. 10. Mini intro toKubernetes 10  Launches Docker containers without worrying about the underlying VMs  Dictionary  Pod–a groupofcontainersstartingtogetheron asingle machine  Service –internalloadbalancer,exposinganumberofpodreplicas underasingle address  Ingress– exposesa service underanpublic httpaddress  Everyentity is represented by a YAML object in K8s API server  TheYAML is the desired state, K8s knows how to get there
    11. 11. DeploymentswithHelm 11  Helm – K8s apps management  Chart – a bunch of K8s YAML descriptors, with a simple templating  Whole AEMdeployment canbe installed/upgraded with a single command Image:https://helm.sh
    12. 12. 12 Architecture overview
    13. 13. AEMKubernetessetup 13
    14. 14. 14 Publishpersistence evolution
    15. 15. Problemdefinition 15  Author persistence is easy-ish with MongoDB  Publish is harder –local SegmentMK, no clustering  Thepublish farm is kept up-to-date with replication  However:  weneed toprovidethenew publishinstanceswitha segment store,  copyit fromanotherinstance.  Problems:  copyingfiles betweenpodsis hardandhacky,  whatif there’snopublishto copyfrom?
    16. 16. Cloud SegmentStore 16  A new plugin for the Segment Node Store  Nodes are stored in a cloud storage service  No tar files, raw segments grouped in dirs  Can be used in RW or RO modes
    17. 17. Goldenpublish 17  A designated publish instance  Not connectedto LB  It maintainsa “golden copy” of the segmentstore  New publish just clone it
    18. 18. Problem:duplicatedbinaries andstartuptime 18 Golden publish Segment 1 Segment 2 Segment 4 Segment 3 Segment x Publish 1 Segment 1 Segment 2 Segment 4 Segment 3 Segment y Publish 2 Segment 1 Segment 2 Segment 4 Segment 3 Segment z Publish 3 (starting) Segment 1 Segment 2 Segment 3 Segment 4  Multiple copies of the same segments 1-4 ($$$)  Cloning a bucket takes time during the publish start ( 🕑🕑🕑)
    19. 19. Optimization:a singlesegmentstore 19
    20. 20. 20 Publishpersistence: compaction
    21. 21. Compaction 21
    22. 22. Out-of-bandpublish update 22  This pattern willbe usefulin many cases  We may clone thepublish repository, modify it and re-deploy instanceson top of it  Persisted message queuewill apply missingchanges
    23. 23. 23 Sidecar services
    24. 24. Sidecar approach 24  A single pod can run many containers, sharing their volumes and localhost interface  We can use them for the auxiliaryservices (sidecars):  Dispatcher in the publish pod  Upload logs to Splunk  Warmup service
    25. 25. AEMpod withsidecars 25Sidecaricon: Flaticons.com
    26. 26. 26 Jobs
    27. 27. Kubernetesjob 27  Starts a pod  Meantto perform a specific task and finish  Unlikethe deployment, which run indefinitely  Willbe restarted if fails  Jobs provides a way to interactwiththe deployed AEM
    28. 28. 28 Contentmigration
    29. 29. Contentmigration 29  How to migrate old content to K8s?  Access problem  old AEM envs shouldn’t have access to the K8s (encapsulation)  K8s shouldn’t be able to access oldAEMs (they can be installed anywhere)  Solution:demilitarized zone
    30. 30. 2-phasemigration 30  Phase 1  Themigrator tool (crx2oak-like jar) is used to export old AEM content into a cloud storage service  Phase 2  A Kubernetes job is used to apply the migrated content on the cloud instances
    31. 31. 31 Newindexes
    32. 32. Addingnew index 32  Indexesaretricky  /oak:index is a part of the mutable content  But indexdefinitions belongs to the application  Onlyaddingnew indexesis supported  Whena new indexis addedin /oak:index,it’ll haveanextra useIfExistspropertyreferencing immutable part/apps  This bounds the index definition tothe application version andDocker image  This /appspathhaveto beaddedas well • /oak:index/my-new-index • useIfExists: /apps/indexes@v3 • /apps/indexes • v3: true Mutable part Immutable part
    33. 33. Mutablecontent:addingnew index 33  Indexingjob should be runbefore the actual app deployment  Thejob will: 1. Look forthe new index defs in /oak:index 2. Perform out of band indexing ofthe content 3. Save the new indexing content tothe production repository  TheuseIfExists will makesure that the newindexis ignored, untilthe newimageis installed  When the new image is deployed, the /apps part will be updated and the new index will beused
    34. 34. 34 Other topics
    35. 35. Relatedtopics 35  Feature model usage in Docker (covered in David’s and Karl’stalk)  Replication (covered in Timothee’s talk)  Monitoring with Prometheus and Grafana  CI/CD pipeline  Network policies  …
    36. 36. 36 Thanks!

    Editor's Notes

  • Hello! My name is Tomek Rękawek, I work for Adobe.

    In this presentation I‘ll tell you abou the cloud setup for AEM that we‘re workin on.

    I won‘t be able to cover any dates, licensing or prices,

    but I‘ll show as many technical details as possible, so I hope you‘ll enjoy it.
  • More Related Content

    Related Books

    Free with a 30 day trial from Scribd

    See all

    Related Audiobooks

    Free with a 30 day trial from Scribd

    See all

    ×