การสร้างอิมเมจ Spring Boot: กำหนดค่าพร็อกซีของ Paketo builder

ส่งตัวแปรพร็อกซีไปยัง Paketo builder ผ่าน Gradle bootBuildImage หรือ Maven image.env แยกจากเครื่องมือสร้างและ Docker daemon

เครื่องมือสร้างอาจแก้ไข dependencies ได้สำเร็จ แต่ Paketo buildpack ไม่สามารถดาวน์โหลด runtime ได้ buildpack ทำงานอยู่ภายในคอนเทนเนอร์ของ builder และต้องการอินพุตพร็อกซีของตัวเอง

งาน bootBuildImage ของ Gradle

ใน Groovy build.gradle ที่ใช้งาน bootBuildImage ที่มีอยู่ของ Spring Boot:

tasks.named("bootBuildImage") {
    environment["HTTP_PROXY"] = "http://proxy.example:8080"
    environment["HTTPS_PROXY"] = "http://proxy.example:8080"
}

ปลั๊กอิน Maven ใช้ image.env

สำหรับ spring-boot:build-image ให้วางค่าเหล่านี้ไว้ใต้ image.env ในการกำหนดค่าปลั๊กอิน Spring Boot Maven ที่มีอยู่:

<configuration>
  <image>
    <env>
      <HTTP_PROXY>http://proxy.example:8080</HTTP_PROXY>
      <HTTPS_PROXY>http://proxy.example:8080</HTTPS_PROXY>
    </env>
  </image>
</configuration>

ทั้งสภาพแวดล้อมของงาน Gradle และ image.env ของ Maven ต่างให้ค่าแก่ builder ชื่อทั้งสองอาจหมายถึงตัวกลาง HTTP ธรรมดาตัวเดียวกัน รวมถึง URL ของ artefact แบบ HTTPS สำหรับการดาวน์โหลด artefact สาธารณะที่อนุญาตผ่านพร็อกซีสาธารณะ รายการพร็อกซี HTTP มีผู้สมัครสำหรับค่าของ builder เหล่านี้

การตั้งค่านี้ไม่ขึ้นกับคุณสมบัติ systemProp.http.proxyHost ของ Gradle คุณสมบัติเหล่านั้นเป็นของ JVM และไม่ได้กำหนดค่ากระบวนการอื่นใน builder โดยอัตโนมัติ

Docker daemon ต้องได้รับอิมเมจ builder และอิมเมจรันที่จำเป็นก่อน ความล้มเหลวของ registry ในขั้นตอนก่อนหน้านั้นต้องใช้เส้นทางและการกำหนดค่า registry ของ daemon ไม่ใช่ตัวแปรที่ส่งให้ buildpack ที่ยังไม่เริ่มทำงาน

ใช้ปลายทางพร็อกซีที่เข้าถึงได้จากคอนเทนเนอร์ของ builder ที่อยู่ loopback ของมันระบุคอนเทนเนอร์นั้น ไม่จำเป็นต้องเป็นเวิร์กสเตชันของผู้พัฒนา

รักษาสภาพแวดล้อมการรันของแอปพลิเคชันสุดท้ายอย่างตั้งใจด้วย การเข้าถึงตอนสร้างและเส้นทางที่ใช้เมื่อแอปพลิเคชันรันในภายหลังเป็นการตัดสินใจกำหนดค่าคนละเรื่อง

บทความที่เกี่ยวข้อง