airflow
Apache Airflow 2.10.3
Apache Airflow (หรือเรียกง่ายๆ ว่า Airflow) เป็นแพลตฟอร์มสำหรับเขียน กำหนดเวลา และติดตามเวิร์กโฟลว์โดยทางโปรแกรม
เมื่อเวิร์กโฟลว์ถูกกำหนดให้เป็นโค้ด เวิร์กโฟลว์เหล่านั้นจะสามารถบำรุงรักษา กำหนดเวอร์ชันได้ ทดสอบได้ และทำงานร่วมกันได้มากขึ้น
ใช้ Airflow เพื่อเขียนเวิร์กโฟลว์เป็นกราฟอะไซคลิกโดยตรง (DAG) ของงาน ตัวกำหนดเวลา Airflow ดำเนินงานของคุณบนอาร์เรย์ของผู้ปฏิบัติงานในขณะที่ติดตามการขึ้นต่อกันที่ระบุ ยูทิลิตี้บรรทัดคำสั่งที่หลากหลายทำให้การผ่าตัดที่ซับซ้อนบน DAG เป็นเรื่องง่าย อินเทอร์เฟซผู้ใช้ที่หลากหลายทำให้ง่ายต่อการเห็นภาพไปป์ไลน์ที่ใช้งานจริง ติดตามความคืบหน้า และแก้ไขปัญหาเมื่อจำเป็น
สารบัญ
การไหลเวียนของอากาศทำงานได้ดีที่สุดกับขั้นตอนการทำงานที่ส่วนใหญ่จะคงที่และเปลี่ยนแปลงอย่างช้าๆ เมื่อโครงสร้าง DAG คล้ายกันตั้งแต่รันหนึ่งไปยังอีกรันหนึ่ง จะทำให้เกิดความชัดเจนในหน่วยงานของงานและความต่อเนื่อง โครงการที่คล้ายกันอื่นๆ ได้แก่ Luigi, Oozie และ Azkaban
โดยทั่วไปจะใช้ Airflow ในการประมวลผลข้อมูล แต่มีความเห็นว่างานต่างๆ ควรเป็นแบบเดิม (กล่าวคือ ผลลัพธ์ของงานจะเหมือนกัน และจะไม่สร้างข้อมูลที่ซ้ำกันในระบบปลายทาง) และไม่ควรส่งผ่านข้อมูลปริมาณมาก จากงานหนึ่งไปยังอีกงานหนึ่ง (แม้ว่างานสามารถส่งผ่านข้อมูลเมตาได้โดยใช้คุณสมบัติ XCom ของ Airflow) สำหรับงานที่มีข้อมูลจำนวนมาก แนวทางปฏิบัติที่ดีที่สุดคือการมอบหมายบริการภายนอกที่เชี่ยวชาญงานประเภทนั้น
Airflow ไม่ใช่โซลูชันการสตรีม แต่มักใช้ในการประมวลผลข้อมูลแบบเรียลไทม์ โดยดึงข้อมูลออกจากสตรีมเป็นชุด
Apache Airflow ได้รับการทดสอบด้วย:
| เวอร์ชันหลัก (dev) | เวอร์ชันเสถียร (2.10.3) | |
|---|---|---|
| หลาม | 3.9, 3.10, 3.11, 3.12 | 3.8, 3.9, 3.10, 3.11, 3.12 |
| แพลตฟอร์ม | AMD64/ARM64(*) | AMD64/ARM64(*) |
| คูเบอร์เนเตส | 1.28, 1.29, 1.30, 1.31 | 1.27, 1.28, 1.29, 1.30 น |
| PostgreSQL | 13, 14, 15, 16, 17 | 12, 13, 14, 15, 16 |
| MySQL | 8.0, 8.4, นวัตกรรม | 8.0, 8.4, นวัตกรรม |
| SQLite | 3.15.0+ | 3.15.0+ |
* การทดลอง
หมายเหตุ : MariaDB ไม่ได้รับการทดสอบ/แนะนำ
หมายเหตุ : SQLite ใช้ในการทดสอบ Airflow ห้ามใช้ในการผลิต เราขอแนะนำให้ใช้ SQLite เวอร์ชันเสถียรล่าสุดสำหรับการพัฒนาในเครื่อง
หมายเหตุ : ปัจจุบัน Airflow สามารถทำงานได้บนระบบปฏิบัติการที่รองรับ POSIX สำหรับการพัฒนานั้น มีการทดสอบเป็นประจำบน Linux Distros ที่ค่อนข้างทันสมัยและ macOS เวอร์ชันล่าสุด บน Windows คุณสามารถรันผ่าน WSL2 (ระบบย่อย Windows สำหรับ Linux 2) หรือผ่าน Linux Containers ติดตามงานเพื่อเพิ่มการรองรับ Windows ได้ใน #10388 แต่ไม่ได้มีความสำคัญสูง คุณควรใช้ดิสทริบิวต์บน Linux เป็นสภาพแวดล้อมการดำเนินการ "การผลิต" เท่านั้น เนื่องจากนี่เป็นสภาพแวดล้อมเดียวที่ได้รับการสนับสนุน distro เดียวที่ใช้ในการทดสอบ CI ของเราและใช้ในภาพ DockerHub ที่จัดการโดยชุมชนคือ Debian Bookworm
ไปที่เอกสารประกอบเว็บไซต์ Airflow อย่างเป็นทางการ (รีลีส เสถียร ล่าสุด) เพื่อรับความช่วยเหลือในการติดตั้ง Airflow การเริ่มต้นใช้งาน หรือดูบทแนะนำสอนการใช้งานที่สมบูรณ์ยิ่งขึ้น
หมายเหตุ: หากคุณกำลังมองหาเอกสารสำหรับสาขาหลัก (สาขาการพัฒนาล่าสุด): คุณสามารถค้นหาได้ที่ s.apache.org/airflow-docs
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับข้อเสนอการปรับปรุงการไหลของอากาศ (AIP) โปรดไปที่ Airflow Wiki
เอกสารประกอบสำหรับโปรเจ็กต์ที่ต้องพึ่งพา เช่น แพ็คเกจผู้ให้บริการ, อิมเมจ Docker, แผนภูมิ Helm คุณจะพบได้ในดัชนีเอกสารประกอบ
เราเผยแพร่ Apache Airflow เป็นแพ็คเกจ apache-airflow ใน PyPI การติดตั้งอาจยุ่งยากในบางครั้งเนื่องจาก Airflow เป็นเพียงไลบรารีและแอปพลิเคชันเล็กน้อย ไลบรารีมักจะเปิดการขึ้นต่อกันไว้ และแอปพลิเคชันมักจะปักหมุดไว้ แต่เราไม่ควรดำเนินการทั้งสองอย่างพร้อมกัน เราตัดสินใจที่จะคงการขึ้นต่อกันของเราให้เปิดกว้างที่สุดเท่าที่จะเป็นไปได้ (ใน pyproject.toml ) เพื่อให้ผู้ใช้สามารถติดตั้งไลบรารีเวอร์ชันต่างๆ ได้หากจำเป็น ซึ่งหมายความว่า pip install apache-airflow จะไม่ทำงานเป็นครั้งคราวหรือจะสร้างการติดตั้ง Airflow ที่ไม่สามารถใช้งานได้
อย่างไรก็ตาม เพื่อให้การติดตั้งซ้ำได้ เราจะเก็บชุดของไฟล์ข้อจำกัด "ที่รู้จักว่าใช้งานได้" ไว้ในสาขา orphan constraints-main และ constraints-2-0 เราเก็บไฟล์ข้อจำกัด "ที่ทราบแล้วว่าใช้งานได้" เหล่านั้นแยกกันตามเวอร์ชัน Python หลัก/รอง คุณสามารถใช้เป็นไฟล์จำกัดเมื่อติดตั้ง Airflow จาก PyPI โปรดทราบว่าคุณต้องระบุแท็ก/เวอร์ชัน/สาขา Airflow และเวอร์ชัน Python ที่ถูกต้องใน URL
หมายเหตุ: ขณะนี้รองรับเฉพาะการติดตั้ง
pipอย่างเป็นทางการเท่านั้น
แม้ว่าจะสามารถติดตั้ง Airflow ด้วยเครื่องมืออย่าง Poetry หรือ pip-tools ได้ แต่เครื่องมือเหล่านี้ไม่ได้ใช้ขั้นตอนการทำงานเดียวกันกับ pip โดยเฉพาะอย่างยิ่งเมื่อเป็นเรื่องของการจัดการข้อจำกัดและข้อกำหนด ขณะนี้ยังไม่รองรับการติดตั้งผ่าน Poetry หรือ pip-tools
มีปัญหาที่ทราบเกี่ยวกับ bazel ที่อาจนำไปสู่การพึ่งพาแบบวงกลมเมื่อใช้เพื่อติดตั้ง Airflow โปรดเปลี่ยนไปใช้ pip หากคุณประสบปัญหาดังกล่าว ชุมชน Bazel ทำงานเพื่อแก้ไขปัญหาใน this PR <https://github.com/bazelbuild/rules_python/pull/1166> _ ดังนั้นจึงอาจเป็นไปได้ว่า bazel เวอร์ชันใหม่กว่าจะจัดการได้
หากคุณต้องการติดตั้ง Airflow โดยใช้เครื่องมือเหล่านั้น คุณควรใช้ไฟล์ข้อจำกัดและแปลงเป็นรูปแบบและขั้นตอนการทำงานที่เหมาะสมที่เครื่องมือของคุณต้องการ
pip install ' apache-airflow==2.10.3 '
--constraint " https://raw.githubusercontent.com/apache/airflow/constraints-2.10.3/constraints-3.9.txt "pip install ' apache-airflow[postgres,google]==2.10.3 '
--constraint " https://raw.githubusercontent.com/apache/airflow/constraints-2.10.3/constraints-3.9.txt "สำหรับข้อมูลเกี่ยวกับการติดตั้งแพ็คเกจผู้ให้บริการ โปรดตรวจสอบผู้ให้บริการ
Apache Airflow เป็นโครงการ Apache Software Foundation (ASF) และการเผยแพร่ซอร์สโค้ดอย่างเป็นทางการของเรา:
ตามกฎ ASF แพ็คเกจต้นทางที่เผยแพร่จะต้องเพียงพอสำหรับผู้ใช้ในการสร้างและทดสอบการเปิดตัวโดยที่พวกเขาสามารถเข้าถึงแพลตฟอร์มและเครื่องมือที่เหมาะสม
มีวิธีอื่นในการติดตั้งและใช้งาน Airflow นี่เป็นวิธีการ "สะดวก" - ไม่ใช่ "การเผยแพร่อย่างเป็นทางการ" ตามที่ระบุไว้ใน ASF Release Policy แต่สามารถใช้ได้โดยผู้ใช้ที่ไม่ต้องการสร้างซอฟต์แวร์ด้วยตนเอง
ตามลำดับวิธีการติดตั้ง Airflow ที่พบบ่อยที่สุด:
pip มาตรฐานdocker ใช้ใน Kubernetes, Helm Charts, docker-compose , docker swarm ฯลฯ คุณสามารถอ่านเพิ่มเติมเกี่ยวกับการใช้ การปรับแต่ง และการขยายรูปภาพในเอกสารล่าสุด และเรียนรู้รายละเอียดเกี่ยวกับระบบภายใน ในเอกสารภาพสิ่งประดิษฐ์ทั้งหมดเหล่านั้นไม่ใช่การเผยแพร่อย่างเป็นทางการ แต่จัดทำขึ้นโดยใช้แหล่งข้อมูลที่เผยแพร่อย่างเป็นทางการ สิ่งประดิษฐ์เหล่านั้นบางส่วนเป็น "การพัฒนา" หรือ "ก่อนเผยแพร่" และมีการทำเครื่องหมายไว้อย่างชัดเจนตามนโยบาย ASF
DAGs : ภาพรวมของ DAG ทั้งหมดในสภาพแวดล้อมของคุณ
ตาราง : การแสดงตารางของ DAG ที่ครอบคลุมช่วงเวลา
กราฟ : การแสดงภาพการขึ้นต่อกันของ DAG และสถานะปัจจุบันสำหรับการรันเฉพาะ
ระยะเวลางาน : เวลาทั้งหมดที่ใช้ในงานต่างๆ ในช่วงเวลาหนึ่ง
Gantt : ระยะเวลาและการทับซ้อนกันของ DAG
รหัส : วิธีที่รวดเร็วในการดูซอร์สโค้ดของ DAG
ตั้งแต่ Airflow 2.0.0 เรารองรับแนวทาง SemVer ที่เข้มงวดสำหรับแพ็คเกจทั้งหมดที่เปิดตัว
มีกฎเฉพาะบางประการที่เราตกลงที่จะกำหนดรายละเอียดเวอร์ชันของแพ็คเกจต่างๆ:
google 4.1.0 และ amazon 3.0.3 สามารถติดตั้งกับ Airflow 2.1.2 ได้อย่างมีความสุข หากมีข้อจำกัดของการพึ่งพาข้ามกันระหว่างผู้ให้บริการและแพ็คเกจ Airflow ข้อจำกัดเหล่านั้นจะแสดงอยู่ในผู้ให้บริการเป็นข้อจำกัด install_requires เรามุ่งหวังที่จะรักษาความเข้ากันได้แบบย้อนหลังของผู้ให้บริการกับเวอร์ชัน Airflow 2 ที่เปิดตัวก่อนหน้านี้ทั้งหมด แต่บางครั้งอาจมีการเปลี่ยนแปลงที่อาจทำให้ผู้ให้บริการบางรายหรือทั้งหมดระบุเวอร์ชัน Airflow ขั้นต่ำไว้วงจรการใช้งานเวอร์ชัน Apache Airflow:
| เวอร์ชัน | แพตช์ปัจจุบัน/ไมเนอร์ | สถานะ | การเปิดตัวครั้งแรก | การสนับสนุนที่จำกัด | EOL/สิ้นสุดแล้ว |
|---|---|---|---|---|---|
| 2 | 2.10.3 | รองรับ | 17 ธันวาคม 2020 | จะแจ้งภายหลัง | จะแจ้งภายหลัง |
| 1.10 | 1.10.15 | EOL | 27 ส.ค. 2018 | 17 ธันวาคม 2020 | 17 มิถุนายน 2021 |
| 1.9 | 1.9.0 | EOL | 03 มกราคม 2018 | 27 ส.ค. 2018 | 27 ส.ค. 2018 |
| 1.8 | 1.8.2 | EOL | 19 มี.ค. 2017 | 03 มกราคม 2018 | 03 มกราคม 2018 |
| 1.7 | 1.7.1.2 | EOL | 28 มี.ค. 2559 | 19 มี.ค. 2017 | 19 มี.ค. 2017 |
เวอร์ชันการสนับสนุนที่จำกัดจะได้รับการสนับสนุนด้านความปลอดภัยและการแก้ไขข้อบกพร่องที่สำคัญเท่านั้น เวอร์ชัน EOL จะไม่ได้รับการแก้ไขหรือการสนับสนุนใดๆ เราแนะนำให้ผู้ใช้ทุกคนรันเวอร์ชันรองล่าสุดที่มีอยู่เสมอสำหรับเวอร์ชันหลักใดก็ตามที่ใช้งานอยู่ เราขอแนะนำ เป็นอย่างยิ่ง ให้อัปเกรดเป็น Airflow เวอร์ชันหลักล่าสุดในเวลาที่สะดวกที่สุดและก่อนวัน EOL
ใน Airflow 2.0 เราได้ยอมรับกฎบางอย่างที่เราปฏิบัติตามสำหรับการรองรับ Python และ Kubernetes อิงตามกำหนดการเปิดตัวอย่างเป็นทางการของ Python และ Kubernetes ซึ่งสรุปไว้อย่างดีในคู่มือนักพัฒนา Python และนโยบายการบิดเบือนเวอร์ชันของ Kubernetes
เรายกเลิกการรองรับเวอร์ชัน Python และ Kubernetes เมื่อถึง EOL ยกเว้น Kubernetes เวอร์ชันจะยังคงได้รับการสนับสนุนโดย Airflow หากผู้ให้บริการคลาวด์รายใหญ่สองรายยังคงให้การสนับสนุน เรายกเลิกการรองรับเวอร์ชัน EOL เหล่านั้นในหลักหลังจากวันที่ EOL และจะถูกลบออกอย่างมีประสิทธิภาพเมื่อเราเปิดตัว MINOR ใหม่ตัวแรก (หรือ MAJOR หากไม่มีเวอร์ชัน MINOR ใหม่) ของ Airflow ตัวอย่างเช่น สำหรับ Python 3.9 หมายความว่าเราจะยกเลิกการรองรับใน main right หลังจากวันที่ 27.06.2023 และ Airflow เวอร์ชัน MAJOR หรือ MINOR แรกที่เปิดตัวหลังจากนั้นจะไม่มีการสนับสนุน
เรารองรับ Python/Kubernetes เวอร์ชันใหม่ใน main หลังจากเปิดตัวอย่างเป็นทางการ ทันทีที่เราทำให้มันทำงานในไปป์ไลน์ CI ของเรา (ซึ่งอาจไม่ได้เกิดขึ้นทันทีเนื่องจากการขึ้นต่อกันของ Python เวอร์ชันใหม่เป็นส่วนใหญ่) เราจะปล่อยอิมเมจใหม่ /support ใน Airflow ตามการตั้งค่า CI ที่ทำงาน
นโยบายนี้เป็นความพยายามอย่างดีที่สุด ซึ่งหมายความว่าอาจมีสถานการณ์ที่เราอาจยุติการสนับสนุนเร็วกว่าปกติหากสถานการณ์จำเป็น
ชุมชน Airflow จัดเตรียมอิมเมจคอนเทนเนอร์ที่จัดแพ็คเกจไว้อย่างสะดวกสบาย ซึ่งจะเผยแพร่เมื่อใดก็ตามที่เราเผยแพร่ Apache Airflow รุ่นต่างๆ รูปภาพเหล่านั้นประกอบด้วย:
เวอร์ชันของอิมเมจ OS พื้นฐานคือเวอร์ชันเสถียรของ Debian Airflow รองรับการใช้เวอร์ชันเสถียรที่ใช้งานอยู่ทั้งหมด - ทันทีที่การขึ้นต่อกันของ Airflow ทั้งหมดรองรับการสร้าง และเราได้ตั้งค่าไปป์ไลน์ CI สำหรับการสร้างและทดสอบเวอร์ชันของระบบปฏิบัติการ ประมาณ 6 เดือนก่อนสิ้นสุดการสนับสนุนระบบปฏิบัติการเวอร์ชันเสถียรก่อนหน้าตามปกติ Airflow จะเปลี่ยนอิมเมจที่เผยแพร่ไปใช้ระบบปฏิบัติการเวอร์ชันล่าสุดที่รองรับ
ตัวอย่างเช่น การเปลี่ยนจาก Debian Bullseye เป็น Debian Bookworm ได้ถูกนำมาใช้ก่อนการเปิดตัว 2.8.0 ในเดือนตุลาคม 2023 และ Debian Bookworm จะเป็นตัวเลือกเดียวที่รองรับตั้งแต่ Airflow 2.10.0
ผู้ใช้จะยังคงสามารถสร้างอิมเมจของตนโดยใช้ Debian ที่เสถียรรุ่นต่างๆ จนกว่าจะสิ้นสุดการสนับสนุนตามปกติและสร้างและตรวจสอบอิมเมจที่เกิดขึ้นใน CI ของเรา แต่ไม่มีการทดสอบหน่วยใดดำเนินการโดยใช้อิมเมจนี้ในสาขา main
Airflow มีการขึ้นต่อกันมากมาย - ทางตรงและทางสกรรมกริยา นอกจากนี้ Airflow ก็เป็นทั้ง - ไลบรารีและแอปพลิเคชัน ดังนั้นนโยบายของเราสำหรับการขึ้นต่อกันจึงต้องมีทั้ง - ความเสถียรของการติดตั้งแอปพลิเคชัน แต่ยังรวมถึงความสามารถในการติดตั้งเวอร์ชันที่ใหม่กว่าสำหรับผู้ใช้ที่พัฒนา DAG เราได้พัฒนาแนวทางที่ใช้ constraints เพื่อให้แน่ใจว่าสามารถติดตั้งการไหลเวียนของอากาศในลักษณะที่ทำซ้ำได้ ในขณะที่เราไม่ได้จำกัดผู้ใช้ให้อัปเกรดการพึ่งพาส่วนใหญ่ ด้วยเหตุนี้ เราจึงตัดสินใจว่าจะไม่ใช้ขอบเขตบนของการขึ้นต่อกันของ Airflow เป็นค่าเริ่มต้น เว้นแต่เราจะมีเหตุผลที่ดีที่จะเชื่อว่าขอบเขตบนนั้นจำเป็น เนื่องจากความสำคัญของการขึ้นต่อกันตลอดจนความเสี่ยงที่เกี่ยวข้องกับการอัพเกรดการขึ้นต่อกันเฉพาะ นอกจากนี้เรายังกำหนดขอบเขตบนของการขึ้นต่อกันที่เรารู้ว่าทำให้เกิดปัญหาอีกด้วย
กลไกข้อจำกัดของเราดูแลเกี่ยวกับการค้นหาและอัปเกรดการขึ้นต่อกันที่ไม่ใช่ขอบเขตบนทั้งหมดโดยอัตโนมัติ (โดยมีเงื่อนไขว่าการทดสอบทั้งหมดผ่าน) ความล้มเหลวในการสร้าง main ของเราจะระบุในกรณีที่มีเวอร์ชันของการขึ้นต่อกันที่ทำลายการทดสอบของเรา - บ่งชี้ว่าเราควรผูกมัดด้านบนหรือเราควรแก้ไขโค้ด/การทดสอบของเราเพื่อพิจารณาการเปลี่ยนแปลงขั้นต้นจากการขึ้นต่อกันเหล่านั้น
เมื่อใดก็ตามที่เราพึ่งพาขอบเขตบน เราควรแสดงความคิดเห็นเสมอว่าทำไมเราถึงทำสิ่งนั้น กล่าวคือ เราควรมีเหตุผลที่ดีว่าทำไมการพึ่งพาจึงเป็นขอบเขตบน และเราควรพูดถึงเงื่อนไขในการถอดการผูกออกด้วย
การพึ่งพาเหล่านั้นจะถูกเก็บรักษาไว้ใน pyproject.toml
มีการขึ้นต่อกันเพียงไม่กี่รายการที่เราตัดสินใจว่ามีความสำคัญพอที่จะกำหนดขอบเขตบนตามค่าเริ่มต้น เนื่องจากเป็นที่ทราบกันดีว่าเป็นไปตามรูปแบบการกำหนดเวอร์ชันที่คาดเดาได้ และเรารู้ว่าเวอร์ชันใหม่มีแนวโน้มที่จะนำมาซึ่งการเปลี่ยนแปลงครั้งใหญ่ เรามุ่งมั่นที่จะตรวจสอบและพยายามอัปเกรดการอ้างอิงเป็นเวอร์ชันที่ใหม่กว่าเมื่อมีการเผยแพร่เป็นประจำ แต่นี่เป็นกระบวนการที่ดำเนินการโดยเจ้าหน้าที่
การพึ่งพาที่สำคัญคือ:
SQLAlchemy : ขอบเขตบนของเวอร์ชัน MINOR ที่เฉพาะเจาะจง (SQLAlchemy เป็นที่ทราบกันดีว่าลบการเลิกใช้งานและแนะนำการเปลี่ยนแปลงที่แตกหักโดยเฉพาะอย่างยิ่งการรองรับฐานข้อมูลที่แตกต่างกันจะแตกต่างกันไปและการเปลี่ยนแปลงด้วยความเร็วต่างๆ)Alembic : สิ่งสำคัญคือต้องจัดการการโยกย้ายของเราด้วยวิธีที่คาดเดาได้และมีประสิทธิภาพ ได้รับการพัฒนาร่วมกับ SQLAlchemy ประสบการณ์ของเรากับ Alembic คือมันเสถียรมากในเวอร์ชัน MINORFlask : เราใช้ Flask เป็นกระดูกสันหลังของ UI และ API ของเว็บของเรา เรารู้ว่า Flask เวอร์ชันหลักมีแนวโน้มที่จะทำให้เกิดการเปลี่ยนแปลงแบบทำลายล้าง ดังนั้นการจำกัดให้เหลือเพียงเวอร์ชัน MAJOR จึงสมเหตุสมผลwerkzeug : เป็นที่ทราบกันว่าไลบรารีทำให้เกิดปัญหาในเวอร์ชันใหม่ มีการผนวกรวมเข้ากับไลบรารี Flask อย่างแน่นหนา และเราควรอัปเดตร่วมกันcelery : คื่นฉ่ายเป็นองค์ประกอบสำคัญของ Airflow ตามที่ใช้สำหรับ CeleryExecutor (และที่คล้ายกัน) Celery ติดตาม SemVer ดังนั้นเราควรจำกัดขอบเขตบนของเวอร์ชัน MAJOR ถัดไป นอกจากนี้ เมื่อเราเพิ่มเวอร์ชันบนของไลบรารี เราควรตรวจสอบให้แน่ใจว่าเวอร์ชัน Airflow ขั้นต่ำของผู้ให้บริการ Celery ได้รับการอัปเดตแล้วkubernetes : Kubernetes เป็นองค์ประกอบสำคัญของ Airflow เนื่องจากใช้สำหรับ KubernetesExecutor (และที่คล้ายกัน) ไลบรารี Kubernetes Python ติดตาม SemVer ดังนั้นเราควรผูกไว้บนกับเวอร์ชัน MAJOR ถัดไป นอกจากนี้ เมื่อเราเพิ่มเวอร์ชันบนของไลบรารี เราควรตรวจสอบให้แน่ใจว่าเวอร์ชัน Airflow ขั้นต่ำของผู้ให้บริการ Kubernetes ได้รับการอัปเดตแล้วส่วนหลักของ Airflow คือ Airflow Core แต่ประสิทธิภาพของ Airflow ยังมาจากผู้ให้บริการหลายรายที่ขยายฟังก์ชันการทำงานหลักและเผยแพร่แยกกัน แม้ว่าเราจะเก็บพวกเขา (ในตอนนี้) ไว้ใน monorepo เดียวกันเพื่อความสะดวกก็ตาม คุณสามารถอ่านเพิ่มเติมเกี่ยวกับผู้ให้บริการได้ในเอกสารประกอบของผู้ให้บริการ นอกจากนี้เรายังได้กำหนดนโยบายที่นำมาใช้เพื่อรักษาและปล่อยผู้ให้บริการที่จัดการโดยชุมชน ตลอดจนแนวทางสำหรับผู้ให้บริการชุมชนกับผู้ให้บริการบุคคลที่สามในเอกสารผู้ให้บริการ
extras และการพึ่งพา providers เหล่านั้นจะคงอยู่ใน provider.yaml ของผู้ให้บริการแต่ละราย
ตามค่าเริ่มต้น เราไม่ควรพึ่งพาขอบเขตบนสำหรับผู้ให้บริการ อย่างไรก็ตาม ผู้ดูแลของผู้ให้บริการแต่ละรายอาจตัดสินใจเพิ่มขีดจำกัดเพิ่มเติม (และแสดงเหตุผลด้วยความคิดเห็น)
ต้องการช่วยสร้าง Apache Airflow หรือไม่? ดูคู่มือผู้ร่วมให้ข้อมูลของเราเพื่อดูภาพรวมที่ครอบคลุมเกี่ยวกับวิธีการมีส่วนร่วม รวมถึงคำแนะนำในการตั้งค่า มาตรฐานการเขียนโค้ด และแนวทางการขอดึงข้อมูล
หากคุณแทบรอไม่ไหวที่จะมีส่วนร่วม และต้องการเริ่มต้นโดยเร็วที่สุด ลองดูการเริ่มต้นอย่างรวดเร็วที่นี่
อิมเมจ Docker (คอนเทนเนอร์) อย่างเป็นทางการสำหรับ Apache Airflow มีการอธิบายไว้ในรูปภาพ
+1s ของสมาชิก PMC และผู้กระทำการจะถือเป็นการลงคะแนนเสียงที่มีผลผูกพัน เรารู้จักองค์กรประมาณ 500 แห่งที่ใช้งาน Apache Airflow (แต่น่าจะมีองค์กรอื่นๆ อีกมากมาย) อยู่ในระบบ
หากคุณใช้ Airflow อย่าลังเลที่จะทำการประชาสัมพันธ์เพื่อเพิ่มองค์กรของคุณลงในรายการ
Airflow เป็นงานของชุมชน แต่คณะกรรมการ/ผู้ดูแลหลักมีหน้าที่ตรวจสอบและรวม PRs ตลอดจนควบคุมการสนทนาเกี่ยวกับคำขอคุณสมบัติใหม่ หากคุณต้องการเป็นผู้ดูแล โปรดตรวจสอบข้อกำหนดของคอมมิตเตอร์ Apache Airflow
บ่อยครั้งที่คุณจะเห็นปัญหาที่กำหนดให้กับเหตุการณ์สำคัญเฉพาะด้วยเวอร์ชัน Airflow หรือ PR ที่ถูกรวมเข้ากับสาขาหลัก และคุณอาจสงสัยว่า PR ที่รวมเข้าด้วยกันจะออกรุ่นใด หรือรุ่นใดที่ปัญหาที่ได้รับการแก้ไขจะเป็น คำตอบของเรื่องนี้ก็เป็นไปตามปกติ ขึ้นอยู่กับสถานการณ์ต่างๆ คำตอบนั้นแตกต่างกันสำหรับการประชาสัมพันธ์และประเด็นต่างๆ
เพื่อเพิ่มบริบทเล็กน้อย เรากำลังปฏิบัติตามรูปแบบการกำหนดเวอร์ชันของ Semver ตามที่อธิบายไว้ในกระบวนการเผยแพร่ Airflow รายละเอียดเพิ่มเติมได้รับการอธิบายโดยละเอียดใน README นี้ภายใต้บทเวอร์ชัน Semantic แต่โดยย่อ เรามี Airflow เวอร์ชัน MAJOR.MINOR.PATCH
MAJOR จะเพิ่มขึ้นในกรณีที่มีการเปลี่ยนแปลงMINOR จะเพิ่มขึ้นเมื่อมีการเพิ่มคุณสมบัติใหม่PATCH จะเพิ่มขึ้นเมื่อมีเฉพาะการแก้ไขข้อบกพร่องและการเปลี่ยนแปลงเฉพาะเอกสารเท่านั้น โดยทั่วไปเราจะเผยแพร่ Airflow เวอร์ชัน MINOR จากสาขาที่ตั้งชื่อตามเวอร์ชัน MINOR ตัวอย่างเช่น 2.7.* รีลีสถูกรีลีสจากสาขา v2-7-stable , 2.8.* รีลีสถูกรีลีสจากสาขา v2-8-stable เป็นต้น
โดยส่วนใหญ่ในรอบการเปิดตัวของเรา เมื่อยังไม่มีการสร้างสาขาสำหรับสาขา MINOR ถัดไป PR ทั้งหมดที่รวมเข้ากับ main (เว้นแต่จะถูกเปลี่ยนกลับ) จะหาทางไปสู่การเปิดตัว MINOR ครั้งถัดไป ตัวอย่างเช่น หากรีลีสล่าสุดคือ 2.7.3 และสาขา v2-8-stable ยังไม่ได้สร้าง รีลีส MINOR ถัดไปคือ 2.8.0 และ PR ทั้งหมดที่รวมเข้ากับ main จะถูกปล่อยออกมาใน 2.8.0 อย่างไรก็ตาม PR บางส่วน (แก้ไขข้อบกพร่องและการเปลี่ยนแปลงเฉพาะเอกสาร) เมื่อรวมเข้าด้วยกัน สามารถเลือกเชอร์รี่เป็นสาขา MINOR ปัจจุบันและเผยแพร่ใน PATCHLEVEL รุ่นถัดไป ตัวอย่างเช่น หาก 2.8.1 เปิดตัวแล้วและเรากำลังดำเนินการกับ 2.9.0dev ดังนั้นการทำเครื่องหมาย PR ด้วยเหตุการณ์สำคัญ 2.8.2 หมายความว่าจะถูกเลือกอย่างเชอร์รี่ไปยังสาขา v2-8-test และเผยแพร่ใน 2.8.2rc1 และในที่สุดใน 2.8.2
เมื่อเราเตรียมการสำหรับรุ่น MINOR ถัดไป เราได้ตัดสาขา v2-*-test และ v2-*-stable ใหม่ออก และเตรียมรุ่น alpha และ beta สำหรับเวอร์ชัน MINOR ถัดไป PR ที่รวมเข้ากับ main จะยังคงได้รับการปล่อยตัวในรุ่น MINOR ถัดไป จนกว่าเวอร์ชั่น rc จะถูกตัด สิ่งนี้เกิดขึ้นเนื่องจากสาขา v2-*-test และ v2-*-stable จะถูกรีเบสใหม่ที่ด้านบนของ main เมื่อมีการเตรียมการเผยแพร่ beta และ rc ครั้งถัดไป ตัวอย่างเช่น เมื่อเราตัดเวอร์ชัน 2.10.0beta1 สิ่งใดที่รวมเข้ากับเวอร์ชันหลักก่อนที่ 2.10.0rc1 จะถูกปล่อยออกมา จะหาทางเป็น 2.10.0rc1
จากนั้น เมื่อเราเตรียมผู้สมัคร RC ตัวแรกสำหรับรุ่น MINOR เราจะหยุดการย้ายสาขา v2-*-test และ v2-*-stable และ PR ที่รวมเข้ากับรุ่นหลักจะถูกปล่อยออกมาในรุ่น MINOR ถัดไป อย่างไรก็ตาม PR บางส่วน (แก้ไขข้อบกพร่องและการเปลี่ยนแปลงเฉพาะเอกสาร) เมื่อรวมเข้าด้วยกัน สามารถเลือกเชอร์รี่ไปยังสาขา MINOR ปัจจุบันและเผยแพร่ใน PATCHLEVEL รุ่นถัดไป - ตัวอย่างเช่น เมื่อเวอร์ชันที่ออกล่าสุดจากสาขา v2-10-stable คือ 2.10.0rc1 PR บางส่วนจาก main สามารถทำเครื่องหมายเป็นเหตุการณ์สำคัญ 2.10.0 โดยผู้คอมมิต ผู้จัดการการเปิดตัวจะพยายามเลือกพวกเขาในสาขาการเปิดตัว หากสำเร็จ พวกมันจะถูกปล่อยออกมาใน 2.10.0rc2 และตามมาใน 2.10.0 สิ่งนี้ยังใช้กับเวอร์ชัน PATCHLEVEL ที่ตามมาด้วย เมื่อตัวอย่าง 2.10.1 ได้รับการเผยแพร่แล้ว การทำเครื่องหมาย PR ด้วยเหตุการณ์สำคัญ 2.10.2 หมายความว่าจะถูกเลือกอย่างเชอร์รี่ไปยังสาขา v2-10-stable และเผยแพร่ใน 2.10.2rc1 และในท้ายที่สุดใน 2.10.2
ผู้จัดการฝ่ายปล่อยจะเป็นผู้ตัดสินใจขั้นสุดท้ายเกี่ยวกับการเก็บเชอร์รี่
การทำเครื่องหมายปัญหาด้วยเหตุการณ์สำคัญนั้นแตกต่างออกไปเล็กน้อย โดยปกติแล้ว ผู้ดูแลจะไม่ทำเครื่องหมายปัญหาด้วยเหตุการณ์สำคัญ โดยปกติแล้วจะทำเครื่องหมายไว้ใน PR เท่านั้น หาก PR เชื่อมโยงกับปัญหา (และ "การแก้ไข") ได้รับการผสานและเผยแพร่ในเวอร์ชันเฉพาะตามกระบวนการที่อธิบายไว้ข้างต้น ปัญหาจะถูกปิดโดยอัตโนมัติ จะไม่มีการตั้งค่าเหตุการณ์สำคัญสำหรับปัญหา คุณต้องตรวจสอบ PR ที่ แก้ไขปัญหาเพื่อดูว่ามีการเปิดตัวเวอร์ชันใด
อย่างไรก็ตาม บางครั้งผู้ดูแลจะทำเครื่องหมายปัญหาด้วยเหตุการณ์สำคัญที่เฉพาะเจาะจง ซึ่งหมายความว่าปัญหาดังกล่าวมีความสำคัญในการเป็นผู้สมัครเพื่อดูว่ากำลังเตรียมการเผยแพร่เมื่อใด เนื่องจากนี่เป็นโครงการโอเพ่นซอร์ส ซึ่งโดยพื้นฐานแล้วผู้มีส่วนร่วมทุกคนอาสาสละเวลา จึงไม่รับประกันว่าปัญหาเฉพาะจะได้รับการแก้ไขในเวอร์ชันเฉพาะ เราไม่ต้องการระงับการเผยแพร่เนื่องจากปัญหาบางอย่างไม่ได้รับการแก้ไข ดังนั้นในกรณีดังกล่าว ผู้จัดการการเผยแพร่จะมอบหมายปัญหาที่ไม่ได้รับการแก้ไขดังกล่าวใหม่ให้กับเหตุการณ์สำคัญถัดไป ในกรณีที่ไม่ได้รับการแก้ไขทันเวลาสำหรับการเผยแพร่ปัจจุบัน ดังนั้น เหตุการณ์สำคัญสำหรับปัญหาจึงเป็นจุดประสงค์ที่ควรพิจารณามากกว่าสัญญาว่าจะได้รับการแก้ไขในเวอร์ชัน
บริบทและ คำถามที่พบ บ่อยเพิ่มเติมเกี่ยวกับการเปิดตัวแพตช์ระดับสามารถพบได้ในเอกสารสิ่งที่จะเข้าสู่การเปิดตัวครั้งถัดไปในโฟลเดอร์ dev ของพื้นที่เก็บข้อมูล
ใช่! โปรดปฏิบัติตามนโยบายเครื่องหมายการค้าของมูลนิธิ Apache Foundation และ Brandbook ของ Apache Airflow โลโก้ที่ทันสมัยที่สุดมีอยู่ใน repo นี้และบนเว็บไซต์ Apache Software Foundation
โครงสร้างพื้นฐาน CI สำหรับ Apache Airflow ได้รับการสนับสนุนโดย:
