בניית אימג'ים של Spring Boot: הגדרת ה-proxy של בונה Paketo

כלי בנייה יכול לפתור את התלויות שלו בהצלחה, בעוד buildpack של Paketo אינו מצליח להוריד סביבת ריצה. ה-buildpack פועל בתוך מכולת הבונה וזקוק לקלט proxy משלו.

המשימה bootBuildImage של Gradle

בקובץ build.gradle בסגנון Groovy עם המשימה 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 מספקים ערכים לבונה. שני השמות יכולים לזהות את אותו מתווך HTTP רגיל, גם עבור כתובות URL של ארטיפקטים ב-HTTPS. עבור הורדות ארטיפקטים ציבוריות המותרות דרך פרוקסי ציבוריים, רשימת הפרוקסי של HTTP מספקת מועמדים לערכי הבונה האלה.

הגדרה זו אינה תלויה במאפיינים systemProp.http.proxyHost של Gradle. אלה שייכים ל-JVM ואינם מגדירים אוטומטית תהליך אחר בתוך הבונה.

דמון Docker חייב תחילה להשיג את אימג'י הבונה וההרצה הנדרשים. כשל ברישום בשלב מוקדם זה דורש את המסלול ותצורת הרישום של הדמון, ולא משתנה שנמסר ל-buildpack שעוד לא התחיל.

השתמשו בנקודת קצה של proxy שנגישה ממכולת הבונה. כתובת ה-loopback שלה מזהה את המכולה הזאת, ולא בהכרח את תחנת העבודה של המפתח.

שמרו גם על סביבת ההרצה של האפליקציה הסופית במכוון. הגישה בזמן הבנייה והמסלול שבו משתמשים כשהאפליקציה רצה לאחר מכן הם החלטות תצורה נפרדות.