ເຄື່ອງມື build ສາມາດແກ້ໄຂການອີງໃສ່ຂອງມັນໄດ້ດີ, ແຕ່ Paketo buildpack ບໍ່ສາມາດດາວໂຫລດ runtime ໄດ້. buildpack ເຮັດວຽກຢູ່ໃນ container ຂອງ builder ແລະ ຕ້ອງການຂໍ້ມູນ proxy ຂອງຕົນເອງ.

ວຽກ 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"
}

Plugin ຂອງ Maven ໃຊ້ image.env

ສຳລັບ spring-boot:build-image, ໃສ່ຄ່າເຫຼົ່ານີ້ໄວ້ໃຕ້ image.env ໃນການຕັ້ງຄ່າ plugin 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 ສາທາລະນະທີ່ອະນຸຍາດຜ່ານ proxy ສາທາລະນະ, ລາຍຊື່ proxy HTTP ໃຫ້ຜູ້ສະໝັກສຳລັບຄ່າ builder ເຫຼົ່ານີ້.

ການຕັ້ງຄ່ານີ້ເປັນເອກະລາດຈາກຄຸນສົມບັດ systemProp.http.proxyHost ຂອງ Gradle. ສິ່ງເຫຼົ່ານັ້ນເປັນຂອງ JVM ແລະ ບໍ່ໄດ້ຕັ້ງຄ່າຂະບວນການອື່ນໃນ builder ໂດຍອັດຕະໂນມັດ.

Docker daemon ຕ້ອງໄດ້ຮັບຮູບພາບ builder ແລະ ຮູບພາບການແລ່ນທີ່ຕ້ອງການກ່ອນ. ຄວາມລົ້ມເຫຼວຂອງ registry ໃນຂັ້ນຕອນກ່ອນນັ້ນຕ້ອງການ ເສັ້ນທາງ ແລະ ການຕັ້ງຄ່າ registry ຂອງ daemon, ບໍ່ແມ່ນຕົວແປທີ່ໃຫ້ buildpack ທີ່ຍັງບໍ່ໄດ້ເລີ່ມ.

ໃຊ້ຈຸດສຸດທ້າຍຂອງ proxy ທີ່ເຂົ້າເຖິງໄດ້ຈາກ container ຂອງ builder. ທີ່ຢູ່ loopback ຂອງມັນຊີ້ບອກ container ນັ້ນ, ບໍ່ຈຳເປັນສະຖານີເຮັດວຽກຂອງນັກພັດທະນາ.

ຮັກສາສະພາບແວດລ້ອມການແລ່ນຂອງແອັບຯສຸດທ້າຍໃຫ້ເປັນໄປຕາມເຈດຕະນາ. ການເຂົ້າເຖິງຕອນ build ແລະ ເສັ້ນທາງທີ່ໃຊ້ເມື່ອແອັບຯແລ່ນຕໍ່ມາ ເປັນການຕັດສິນໃຈຕັ້ງຄ່າສອງຢ່າງແຍກກັນ.

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ