การปรับใช้สีน้ำเงิน / เขียวด้วย CloudFront


17

ฉันกำลังมองหาวิธีที่จะทำการใช้งานฟ้า / สีเขียวกับCloudFront

ใครบ้างมีทางออกที่ดีสำหรับการย้ายจากการกระจาย CloudFront หนึ่งไปยังอีกหรือไม่ทุกคนเพียงแค่สร้างการกระจายของพวกเขาและจากนั้นไม่เคยสัมผัสอีกครั้งหรือไม่

การกระจาย CloudFront ของฉันประกอบด้วยต้นกำเนิด S3 หนึ่งรายการสำหรับเนื้อหาแบบคงที่ (javascript ฯลฯ ) และต้นกำเนิดที่กำหนดเองซึ่งชี้ไปที่ AWS ELB

ไม่มีการเปลี่ยนแปลงของ CloudFront

ภายใต้สถานการณ์ปกติเราจะไม่ทำการเปลี่ยนแปลงใด ๆ กับการกระจาย CloudFront ของเราเลย เราเวอร์ชั่นเนื้อหาแบบคงที่ของเราในแหล่งกำเนิด S3 โดยการเปลี่ยนชื่อของไฟล์เนื้อหาแบบคงที่ใน S3 และทำการปรับใช้กับอินสแตนซ์ EC2 ภายใต้ Elastic Load Balancer (ELB) อย่างไรก็ตามมีบางครั้งที่เราจำเป็นต้องทดสอบและทำการเปลี่ยนแปลงการกระจายตัวของ CloudFront หรือมีการเปลี่ยนแปลงที่สำคัญพอกับสภาพแวดล้อมของเราที่เราต้องชี้ไปที่ ELB ใหม่ในสภาพแวดล้อมใหม่

การกระจายของ CloudFront สองรายการ

ตัวเลือกแรกที่ฉันพยายามคือมีการเผยแพร่เว็บ CloudFront สองแบบแยกต่างหากหนึ่งรายการสำหรับปัจจุบันของฉันหรือ A สภาพแวดล้อมและอีกหนึ่งสำหรับสภาพแวดล้อมใหม่หรือ B ของฉัน ฉันพยายามใช้นโยบายการกำหนดเส้นทางแบบถ่วงน้ำหนัก Route53 ซึ่งฉันเพิ่มสองเรคคอร์ดสำหรับเรคคอร์ด www.domain.com Route53 อันหนึ่งชี้ไปที่การแจกจ่าย CloudFront A ที่มีน้ำหนักเท่ากับ 1 และอีกอันชี้ไปที่การแจกจ่าย CloudFront B ที่มีน้ำหนักเท่ากับ 0. แผนจะเปลี่ยนน้ำหนักเมื่อฉันต้องการย้ายจากการแจกจ่าย A ไปยังการกระจาย B อย่างไรก็ตามการกระจาย CloudFront เพียงครั้งเดียวในแต่ละครั้งสามารถลงทะเบียนwww.domain.com Alternate Domain Names (CNAMEs)หรือคุณได้รับข้อผิดพลาดต่อไปนี้:

com.amazonaws.services.cloudfront.model.CNAMEAlreadyExistsException: One or more of the CNAMEs you provided are already associated with a different resource. (Service: AmazonCloudFront; Status Code: 409; Error Code: CNAMEAlreadyExists; Request ID: ef84a5f0-44e7-11e5-9315-0ba167bb108a)

One CloudFront Distribution

ตัวเลือกที่สองคือการกระจายเว็บ CloudFront หนึ่งรายการ ฉันมี S3 และต้นกำเนิดที่กำหนดเองซึ่งชี้ไปที่ทั้งสภาพแวดล้อม A และ B ของฉันจากนั้นฉันจะปรับปรุงลักษณะการทำงานแคชของ CloudFront ให้ชี้ไปที่ต้นกำเนิดอื่นเมื่อฉันต้องการย้ายจากสภาพแวดล้อมหนึ่งไปยังอีกสภาพแวดล้อมหนึ่ง สิ่งนี้ยุ่งมากเพราะการอัปเดตเหล่านี้ใช้เวลา 15-60 นาทีไม่มีการเปิดเผยความคืบหน้าของการอัปเดตและขึ้นอยู่กับลักษณะของการเปลี่ยนแปลงที่คุณอาจต้องติดตามด้วยการยกเลิกการตรวจสอบ CloudFrontดังนั้นคุณจึงไม่แสดงเนื้อหาแคช จากสภาพแวดล้อมเก่าพร้อมกับเนื้อหาใหม่

ขอบคุณสำหรับคำแนะนำ!


คุณพบวิธีแก้ปัญหาหรือไม่? เรามีปัญหาเดียวกันในโครงการของเราและวิธีที่เราทำตอนนี้ - เราเปลี่ยนจุดปลายคลาวด์ฟร้อนท์ด้วยตนเองในโครงการของเรา
Dmytriy Voloshyn

1
น่าเสียดายที่ไม่มี - ฉันไม่คิดว่าจะมีสิ่งที่ดี แนวปฏิบัติที่เหมาะสมที่สุดคือการใช้การแจกจ่ายแบบคลาวด์หนึ่งครั้งเนื้อหาในถัง s3 และใช้บันทึกข้อมูล DNS แบบระบุน้ำหนักเส้นทางสำหรับ 53 ต้นกำเนิดที่ชี้ไปยังเนื้อหาแบบไดนามิก จากนั้นคุณเพียงแค่อัปเดต route53 เพื่อเปลี่ยนเนื้อหาแบบไดนามิกและคุณไม่จำเป็นต้องแตะ cloudfront เรารักษาการกระจายการกระจายของคลาวด์ฟรอนต์แยกต่างหากสำหรับ dev และ qa ตัวอย่าง: stackoverflow.com/questions/9130555/…
Peter M

คำตอบ:


9

Two Cloudfront Distributions

เนื่องจาก AWS อนุญาตให้มีการทับซ้อนระหว่าง CNAME สำรองในบัญชี AWS เดียวกันคุณสามารถสลับระหว่างการแจกแจงแบบคลาวด์สองครั้งในลักษณะดังต่อไปนี้:

  • ใช้ www.domain.com เป็น CNAME สำรองสำหรับการแจก Prod 1
  • ใช้ * .domain.com เป็น CNAME สำรองสำหรับการแจก Prod 2
  • ชี้ CNAME DNS ของคุณ www.domain.com ไปยังการแจกจ่าย 1 หรือการแจกจ่าย 2 (* .cloudfront.net)
  • ลบ CNAME สำรองออกจากการแจกจ่ายที่คุณไม่ต้องการให้บริการเนื้อหาอีกต่อไป

อย่างไรก็ตาม DNS การแจกจ่ายที่แตกต่างกันสองรายการ (* .cloudfront.net) อาจชี้ไปที่โหนดขอบเดียวกันซึ่งหมายความว่าวิธีการแสดงเนื้อหาของคุณคือการจับคู่ cloudfront.net CNAME กับโหนด Edge ที่ให้บริการแล้วจึงจับคู่ด้วย ชื่อโฮสต์ ในกรณีนี้หากทั้งสองดิสทริบิวชันของคุณใช้โหนดขอบเดียวกัน (สามารถตรวจสอบได้ด้วยdig) การตัดจะไม่สะอาด

เช่นหากการแจกแจงทั้งสองใช้ร่วมกันอย่างน้อยหนึ่งโหนดการแจกแจง 1 กับ Alt CNAME www.domain.com จะมีความสำคัญเหนือกว่าการแจกจ่าย 2 ที่มี * .domain.com ทั่วไปมากขึ้นจนกว่า CNAME จะถูกลบออกจากการแจกจ่าย 1 การกำหนดค่าในโหนดขอบทั้งหมด . ดังนั้นเวอร์ชันที่ดึงมาจากคำขอหนึ่งอาจแตกต่างจากคำขออื่นในช่วงระยะเวลาการเปลี่ยนแปลง


เนื่องจากเวลาการแพร่กระจายการเปลี่ยนแปลงขยายใน CloudFront นี่คือตัวเลือกของคุณเท่านั้น
CloudWalker

ขอบคุณ - นี่คือคำตอบที่น่าสนใจอย่างยิ่ง ฉันไม่เคยคิดที่จะทำแบบนี้ ฉันจะทำเครื่องหมายว่าถูกต้องเพราะมันตัดจากการกระจายหนึ่งไปอีกการกระจายหนึ่งอย่างไรก็ตามฉันต้องหลีกเลี่ยงเวลาที่เพิ่มขึ้นอย่างต่อเนื่องและความเสี่ยงในการให้บริการเนื้อหาที่ไม่ถูกต้องในช่วงการเปลี่ยนภาพดังนั้นฉันจึงไม่สามารถใช้งานได้ในกรณีของฉัน . ฉันเห็นด้วยกับ @CloudWalker ว่าไม่มีตัวเลือกอื่น
ปีเตอร์ M

3

ค่อนข้างช้าในเกมที่นี่ แต่สำหรับคนอื่นที่กำลังมองหาสิ่งนี้ ฉันเชื่อว่าสิ่งนี้สามารถทำได้โดยใช้ lambda @ edge คล้ายกับการทดสอบ A / B https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html คุณสามารถนำฟังก์ชั่นแลมบ์ดามาใช้เมื่อผู้ใช้ร้องขอ URL เลือกที่จะให้บริการเนื้อหาสีน้ำเงิน / สีเขียวจากต้นกำเนิดที่แตกต่างกันหรือคำนำหน้า URL ค่าคุกกี้จะกำหนดว่าจะให้บริการการปรับใช้ใด เมื่อคำขอแรกมาถึง (ไม่มีคุกกี้) ให้ตั้งค่าคุกกี้สุ่มว่า 95% สีฟ้า 5% สีเขียว


1

ยิงมาจากสะโพกใช้เวลานานเท่าไหร่ในการเปลี่ยนจุดกำเนิดภายในการกระจายแบบคลาวด์ 1) ปรับใช้รหัสใหม่ที่อยู่เบื้องหลัง ELB อุ่นเครื่อง 2) เพิ่ม ELB นี้เป็นจุดเริ่มต้นใหม่ในการกระจายส่วนหน้าคลาวด์ของคุณในขณะที่ลบต้นกำเนิดเดิม 3) เมื่อตัดเสร็จให้ตัดรหัสเก่าด้านหลัง ELB เก่า

เพื่อหลีกเลี่ยงความล่าช้าที่เกี่ยวข้องกับการอัปเดต CloudFront หรือการอัปเดต DNS คุณสามารถสลับกลุ่มการปรับขนาดอัตโนมัติด้านหลัง ELB ของคุณ 1) ปรับใช้รหัสใหม่ใน ASG ใหม่อุ่นเครื่อง 2) ลงทะเบียน ELB ที่มีอยู่ของคุณกับ ASG ใหม่นี้ 3) ยกเลิกการลงทะเบียน ASG เก่าจาก ELB ของคุณ 4) เมื่อตัดเสร็จ ASG เก่าจะถูกทำลาย


0

ฉันยังได้ทำการวิจัยในหัวข้อนี้และมีวิธีแก้ไข (ดูด้านล่าง)

พื้นหลัง:

CloudFront ต้องการ CNAME ในการกำหนดค่าการกระจายเพื่อให้ไม่ซ้ำกันทั่วทั้งบัญชีของคุณ ดังนั้นการควบคุมสีน้ำเงิน / เขียวผ่าน DNS ไปยังการกระจายที่ต่างกันจะไม่ทำงาน มีแฮ็กกลิ้งไปมาซึ่งจะใช้ไวด์การ์ด แต่ไม่รับประกันว่าไฟล์ที่ถูกต้องจะได้รับการบริการ การควบคุมสีน้ำเงิน / เขียวผ่าน DNS และ CloudFront นั้นไม่สามารถทำได้

นอกจากนี้การเปลี่ยนการตั้งค่าใด ๆ ใน CloudFront (รวมถึง CNAME) จะส่งผลให้รอ 15-60 นาทีในขณะที่การเปลี่ยนแปลงจะถูกส่งไปยังเซิร์ฟเวอร์ขอบ ยังไม่ใช่การตั้งค่าที่เหมาะ

หลีกเลี่ยง:

สำหรับแอปหน้าเดียวการกำหนดค่านี้อาจทำเคล็ดลับ:

  • URL แอป: app.mydomain.com/app
  • โครงสร้าง S3:
    • แอพ / (เว็บไซต์สดของคุณ)
    • app2 / (เว็บไซต์ที่คุณใช้งานไม่ค่อยสด)

ตอนนี้กำหนดค่า CloudFront เพื่อใช้ที่ฝากข้อมูลของคุณเพื่อให้บริการไฟล์ ณ จุดนี้มันทั้งหมดลงมาให้คุณตั้งค่าแคช เนื่องจาก CloudFront ใช้เวลานานตั้งค่าส่วนหัว CacheControl บนวัตถุ S3 ของเรา สำหรับ index.html เราใช้ 5 นาทีทุกอย่างอื่น 1 วัน เมื่อถึงเวลาเปลี่ยนให้สลับชื่อไดเรกทอรี S3 ภายใน 5 นาทีแอพจะแสดงผลทุกการใช้งานและทุกวัตถุประสงค์

สำหรับแอพที่กำลังทำงานอยู่เรามีบิลด์เวอร์ชันบิวด์ติดตั้งไว้ในโค้ดและไฟล์ build config json บนรูทของแอป จากนั้นแอพจะขอไฟล์ json เป็นครั้งคราวตรวจสอบเวอร์ชั่นหากเป็นไฟล์เก่าให้ทำการรีเฟรช

ข้อ จำกัด

คุณไม่สามารถทำการทดสอบแบบแช่ได้เป็นอย่างดี ฉันคิดว่าเป็นไปได้ที่จะเพิ่ม TTL ของ index.html เป็นไม่กี่ชั่วโมงหรือวัน (ขึ้นอยู่กับความต้องการของคุณ) ที่จะช่วยให้มั่นใจว่าลูกค้าจะได้รับเวอร์ชันใหม่เมื่อแคชในพื้นที่ของพวกเขาหมดอายุ


0

ในบล็อกโพสต์นี้ผู้เขียนได้ทำการทดสอบ ab ผ่านทางแลมบ์ดาเอดจ์โดยใช้รหัสในเอกสาร AWS (คุณสามารถดูตัวอย่างได้ที่นี่: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda- samples.html )

โดยทั่วไปสิ่งที่คุณทำคือคุณสร้างการแจกจ่าย Cloudfront เดียวที่ชี้ไปยังต้นกำเนิดที่แตกต่างกันสองแห่ง จากนั้นคุณสามารถใช้แลมบ์ดาเอดจ์เพื่อควบคุมการรับส่งข้อมูลไปยังต้นทาง (ผ่านคุกกี้) และแน่นอนว่าคุณสามารถใช้งานอื่น ๆ ผ่านแลมบ์ดาเช่นการถ่วงน้ำหนักการจราจรหรือพลิกมันเป็นต้นนอกจากนี้ยังง่ายต่อการเพิ่มต้นกำเนิดและตรรกะเพิ่มเติม .

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.