בדף הזה מוסבר איך להתחבר למכונה של Cloud SQL משירות שפועל ב-Cloud Build, ומוצגות דוגמאות.
Cloud SQL הוא שירות מנוהל של מסד נתונים, שבעזרתו אפשר ליצור, לתחזק ולנהל מסדי נתונים רלציוניים בענן.
Cloud Build הוא שירות שמפעיל את גרסאות ה-build שפיתחתם, בתשתית של Google Cloud .
הגדרת מכונה של Cloud SQL
- מפעילים את Cloud SQL Admin API בפרויקט ב- Google Cloud שממנו מתחברים, אם עדיין לא עשיתם את זה:
התפקידים שנדרשים כדי להפעיל ממשקי API
כדי להפעיל ממשקי API, צריך את ההרשאה
serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים - יוצרים מכונה של Cloud SQL ל-SQL Server. כדי לשפר את זמן האחזור, להימנע מחלק מעלויות הרשת ולהפחית את הסיכונים לכשלים בין אזורים, מומלץ לבחור
מיקום למכונה של Cloud SQL באותו אזור שבו נמצא שירות Cloud Build.
כברירת מחדל, Cloud SQL מקצה כתובת IP ציבורית למכונה חדשה. אפשר גם להקצות כתובת IP פרטית. למידע נוסף על אפשרויות הקישוריות של שניהם, קראו את הדף סקירה כללית על התחברות.
- כשיוצרים את המכונה, אפשר לבחור את
ההיררכיה של אישור השרת (CA) של המכונה, ואז להגדיר את ההיררכיה בתור
serverCaModeשל המכונה. כדי להתחבר למכונות מאפליקציות אינטרנט, צריך לבחור באפשרות של רשות אישורים לכל מכונה (GOOGLE_MANAGED_INTERNAL_CA) כמצב של רשות האישורים בשרת.
הגדרת מאגר Artifact Registry
- אם עדיין לא עשיתם את זה, הפעילו את Artifact Registry API בפרויקט ב- Google Cloud שממנו אתם מתחברים:
התפקידים שנדרשים כדי להפעיל ממשקי API
כדי להפעיל ממשקי API, צריך את ההרשאה
serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים - יצירת מאגר Docker ב-Artifact Registry. כדי לשפר את זמן האחזור, להפחית את הסיכון לכשלים בין אזורים ולהימנע מעלויות נוספות של רשתות, מומלץ לבחור מיקום ב-Artifact Registry באותו אזור של שירות Cloud Run.
הגדרת Cloud Build
השלבים להגדרת Cloud Build משתנים בהתאם לסוג כתובת ה-IP שהקציתם למכונה של Cloud SQL.כתובת IP ציבורית (ברירת מחדל)
מוודאים של
חשבון השירות ב-Cloud Build יש את התפקידים וההרשאות ב-IAM שנדרשים כדי להתחבר למכונה של Cloud SQL.
חשבון השירות של Cloud Build מופיע בדף IAM במסוף Google Cloud בתור החשבון הראשי
[YOUR-PROJECT-NUMBER]@cloudbuild..
כדי לראות את חשבון השירות הזה במסוף Google Cloud , צריך לסמן את התיבה Include Google-provided role grants.
לחשבון השירות של Cloud Build צריך להיות תפקיד ה-IAM Cloud SQL Client.
אם חשבון השירות של Cloud Build שייך לפרויקט אחר מזה של מכונת Cloud SQL, צריך להוסיף את Cloud SQL Admin API ואת התפקיד לשני הפרויקטים.
כתובת IP פרטית
כדי להתחבר למכונה של Cloud SQL באמצעות כתובת IP פרטית, Cloud Build צריך להיות באותה רשת VPC כמו המכונה של Cloud SQL. כדי להגדיר את זה:
- מגדירים חיבור פרטי בין רשת ה-VPC של מכונת Cloud SQL לבין רשת הבעלים של השירות המנוהל.
- יוצרים מאגר פרטי של Cloud Build.
אחרי ההגדרה, האפליקציה תוכל להתחבר ישירות באמצעות כתובת ה-IP הפרטית של המכונה והיציאה 1433 כשה-build יופעל במאגר.
התחברות ל-Cloud SQL
אחרי שמגדירים את Cloud Build, אפשר להתחבר למכונה של Cloud SQL.
כתובת IP ציבורית (ברירת מחדל)
בנתיבים של כתובות IP ציבוריות, Cloud Build תומך בשקעי TCP.
אתם יכולים להשתמש ב-Cloud SQL Auth Proxy בשלב של Cloud Build כדי לאפשר חיבורים למסד הנתונים. ההגדרה הזו:
- יוצר את הקונטיינר ומעביר אותו בדחיפה ל-Artifact Registry.
- יוצר קונטיינר שני, ומעתיק אליו את הקובץ הבינארי של Cloud SQL Auth Proxy.
- לא צריך להעביר קונטיינרים שנוצרו על ידי Cloud Build לאף מאגר, והם נמחקים בסיום ה-build.
- באמצעות הקונטיינר השני, מפעיל את Cloud SQL Auth Proxy ומריץ את פקודות ההעברה.
steps: - id: install-proxy name: gcr.io/cloud-builders/wget entrypoint: sh args: - -c - | wget -O /workspace/cloud-sql-proxy https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/2.26.2 chmod +x /workspace/cloud-sql-proxy - id: migrate waitFor: ['install-proxy'] name: YOUR_CONTAINER_IMAGE_NAME entrypoint: sh env: - "DATABASE_NAME=${_DATABASE_NAME}" - "DATABASE_USER=${_DATABASE_USER}" - "DATABASE_PORT=${_DATABASE_PORT}" - "INSTANCE_CONNECTION_NAME=${_INSTANCE_CONNECTION_NAME}" secretEnv: - DATABASE_PASS args: - "-c" - | /workspace/cloud-sql-proxy ${_INSTANCE_CONNECTION_NAME} --port ${_DATABASE_PORT} & sleep 2; # Cloud SQL Proxy is now up and running, add your own logic below to connect python migrate.py # For example options: dynamic_substitutions: true substitutions: _DATABASE_USER: myuser _DATABASE_NAME: mydatabase _INSTANCE_CONNECTION_NAME: ${PROJECT_ID}:us-central1:myinstance _DATABASE_PORT: 1433 _DATABASE_PASSWORD_KEY: database_password _AR_REPO_REGION: us-central1 _AR_REPO_NAME: my-docker-repo _IMAGE_NAME: ${_AR_REPO_REGION}-docker.pkg.dev/${PROJECT_ID}/${_AR_REPO_NAME}/sample-sql-proxy availableSecrets: secretManager: - versionName: projects/$PROJECT_ID/secrets/${_DATABASE_PASSWORD_KEY}/versions/latest env: "DATABASE_PASS"
דוגמת הקוד של Cloud Build ממחישה איך אפשר להריץ סקריפט היפותטי של migrate.py אחרי פריסת האפליקציה לדוגמה הקודמת, כדי לעדכן את מסד הנתונים שלה ב-Cloud SQL באמצעות Cloud SQL Auth Proxy ו-Cloud Build.
כדי להריץ את דוגמת הקוד הזו של Cloud Build, צריך לבצע את השלבים הבאים:
- יוצרים שם לתיקייה
sql-proxy - יוצרים קובץ
Dockerfileבתיקייהsql-proxyעם שורת הקוד הבאה:FROM gcr.io/gcp-runtimes/ubuntu_20_0_4
- יוצרים קובץ
cloudbuild.yamlבתיקייהsql-proxy. - מעדכנים את הקובץ
cloudbuild.yaml:- מעתיקים את הקוד לדוגמה של Cloud Build מהשלב הקודם ומדביקים אותו בקובץ
cloudbuild.yaml. - מעדכנים את הקוד לדוגמה
_DATABASE_PORTבבלוקsubstitutions:ל-1433, שהוא הפורט שמשמש את SQL Server. - מחליפים את הערכים הזמניים לשמירת מקום (פלייסהולדרים) הבאים בערכים שבהם אתם משתמשים בפרויקט:
mydatabasemyusermyinstance
- מעתיקים את הקוד לדוגמה של Cloud Build מהשלב הקודם ומדביקים אותו בקובץ
- יוצרים סוד בשם
database_passwordב-Secret Manager.- כדי שחשבון השירות של Cloud Build יוכל לגשת לסוד הזה, צריך לתת לו את התפקיד מנהל סודות עם גישה לסודות ב-IAM. מידע נוסף זמין במאמר שימוש בסודות מ-Secret Manager.
- יוצרים קובץ סקריפט migrate.py בתיקייה
sql-proxy.- הסקריפט יכול להפנות למשתני הסביבה הבאים ולסוד שנוצר בקובץ
cloudbuild.yamlבאמצעות הדוגמאות הבאות:os.getenv('DATABASE_NAME')os.getenv('DATABASE_USER')os.getenv('DATABASE_PASS')os.getenv('INSTANCE_CONNECTION_NAME')
- כדי להפנות לאותם משתנים מסקריפט Bash (לדוגמה:
migrate.sh), משתמשים בדוגמאות הבאות:$DATABASE_NAME$DATABASE_USER$DATABASE_PASS$INSTANCE_CONNECTION_NAME
- הסקריפט יכול להפנות למשתני הסביבה הבאים ולסוד שנוצר בקובץ
- מריצים את הפקודה הבאה של
gcloud builds submitכדי ליצור קונטיינר עם Cloud SQL Auth Proxy, להפעיל את Cloud SQL Auth Proxy ולהריץ את הסקריפטmigrate.py:gcloud builds submit --config cloudbuild.yaml
כתובת IP פרטית
בנתיבים של כתובות IP פרטיות, האפליקציה מתחברת ישירות למכונה דרך מאגרים פרטיים. בשיטה הזו משתמשים ב-TCP כדי להתחבר ישירות למכונה של Cloud SQL בלי להשתמש ב-Cloud SQL Auth Proxy.
התחברות באמצעות TCP
מתחברים באמצעות כתובת ה-IP הפרטית של מכונת Cloud SQL כמארח וליציאה 1433.
Python
כדי לראות את קטע הקוד הזה בהקשר של אפליקציית אינטרנט, אפשר לעיין ב-README ב-GitHub.
Java
כדי לראות את קטע הקוד הזה בהקשר של אפליקציית אינטרנט, אפשר לעיין ב-README ב-GitHub.
הערה:
- הערך של CLOUD_SQL_CONNECTION_NAME צריך להיות מיוצג בתור <MY-PROJECT>:<INSTANCE-REGION>:<INSTANCE-NAME>
- השימוש בארגומנט ipTypes=PRIVATE יאלץ את SocketFactory להתחבר לכתובת ה-IP הפרטית שמשויכת למכונה
- דרישות הגרסה של JDBC socket factory לקובץ pom.xml
Node.js
כדי לראות את קטע הקוד הזה בהקשר של אפליקציית אינטרנט, אפשר לעיין ב-README ב-GitHub.
המשך
כדי לראות את קטע הקוד הזה בהקשר של אפליקציית אינטרנט, אפשר לעיין ב-README ב-GitHub.
C#
כדי לראות את קטע הקוד הזה בהקשר של אפליקציית אינטרנט, אפשר לעיין ב-README ב-GitHub.
Ruby
כדי לראות את קטע הקוד הזה בהקשר של אפליקציית אינטרנט, אפשר לעיין ב-README ב-GitHub.
PHP
כדי לראות את קטע הקוד הזה בהקשר של אפליקציית אינטרנט, אפשר לעיין ב-README ב-GitHub.
לאחר מכן תוכלו ליצור שלב ב-Cloud Build כדי להריץ את הקוד ישירות.
דוגמת הקוד של Cloud Build שלמעלה מראה איך אפשר להריץ סקריפט migrate היפותטי אחרי פריסת האפליקציה לדוגמה שלמעלה, כדי לעדכן את מסד הנתונים שלה ב-Cloud SQL באמצעות Cloud Build. כדי להריץ את דוגמת הקוד הזו של Cloud Build, צריך לבצע את השלבים הבאים:
- יוצרים שם לתיקייה
sql-private-pool - יוצרים קובץ
Dockerfileבתיקייהsql-private-poolעם שורת הקוד הבאה:FROM gcr.io/gcp-runtimes/ubuntu_20_0_4 - יוצרים קובץ
cloudbuild.yamlבתיקייהsql-private-pool. - מעדכנים את הקובץ
cloudbuild.yaml:- מעתיקים את הקוד לדוגמה של Cloud Build שלמעלה ומדביקים אותו בקובץ
cloudbuild.yaml. - מחליפים את הערכים הזמניים לשמירת מקום (פלייסהולדרים) הבאים בערכים שבהם אתם משתמשים בפרויקט:
mydatabasemyuserdatabasehost, בפורמטhost:port.
- מעתיקים את הקוד לדוגמה של Cloud Build שלמעלה ומדביקים אותו בקובץ
- יוצרים סוד בשם
database_passwordב-Secret Manager.- כדי שחשבון השירות של Cloud Build יוכל לגשת לסוד הזה, צריך לתת לו את התפקיד מנהל סודות עם הרשאת גישה לסודות ב-IAM. מידע נוסף זמין במאמר שימוש בסודות מ-Secret Manager.
- יוצרים קובץ סקריפט migrate.py בתיקייה
sql-proxy.- הסקריפט יכול להפנות למשתני הסביבה הבאים ולסוד שנוצר בקובץ
cloudbuild.yamlבאמצעות הדוגמאות הבאות:os.getenv('DATABASE_NAME')os.getenv('DATABASE_USER')os.getenv('DATABASE_PASS')os.getenv('DATABASE_HOST')
- כדי להפנות לאותם משתנים מסקריפט Bash (לדוגמה:
migrate.sh), משתמשים בדוגמאות הבאות:$DATABASE_NAME$DATABASE_USER$DATABASE_PASS$DATABASE_HOST
- הסקריפט יכול להפנות למשתני הסביבה הבאים ולסוד שנוצר בקובץ
- מריצים את הפקודה הבאה של
gcloud builds submitכדי ליצור קונטיינר עם Cloud SQL Auth Proxy, להפעיל את Cloud SQL Auth Proxy ולהריץ את הסקריפטmigrate.py:gcloud builds submit --config cloudbuild.yaml
שיטות מומלצות ומידע נוסף
אתם יכולים להשתמש ב-Cloud SQL Auth Proxy כשאתם בודקים את האפליקציה באופן מקומי. הוראות מפורטות מופיעות במאמר התחלה מהירה: שימוש ב-Cloud SQL Auth Proxy.
אפשר גם לבדוק באמצעות שרת proxy ל-Cloud SQL דרך קונטיינר של Docker.
העברות של סכימות של מסדי נתונים
אם תגדירו את Cloud Build כך שיתחבר ל-Cloud SQL, תוכלו להריץ משימות של העברת סכימות של מסדי נתונים ב-Cloud Build באמצעות אותו קוד שהייתם פורסים בכל פלטפורמה אחרת בלי שרת (serverless).
שימוש ב-Secret Manager
אתם יכולים להשתמש ב-Secret Manager כדי לכלול מידע רגיש ב-builds.