การย้ายข้อมูลจากแอป Java ของ Google App Engine ไปยัง Cloud Run ด้วย Jib

1. ภาพรวม

Codelab ชุดนี้ (บทแนะนำที่เรียนรู้ได้ด้วยตนเอง) มีเป้าหมายเพื่อช่วยนักพัฒนาซอฟต์แวร์ของ Google App Engine (มาตรฐาน) Java ปรับปรุงแอปให้ทันสมัย โดยแนะนำขั้นตอนการย้ายข้อมูลต่างๆ การทำตามขั้นตอนเหล่านี้จะช่วยให้คุณอัปเดตแอปให้พกพาสะดวกมากขึ้นได้ และตัดสินใจสร้างคอนเทนเนอร์สำหรับ Cloud Run ซึ่งเป็นบริการในเครือของคอนเทนเนอร์โฮสต์ของ Google Cloud ไปยัง App Engine และบริการโฮสต์คอนเทนเนอร์อื่นๆ

บทแนะนำนี้จะสอนวิธีสร้างคอนเทนเนอร์แอป App Engine สำหรับการทำให้ใช้งานได้กับบริการที่มีการจัดการครบวงจรของ Cloud Run โดยใช้ Jib Jib ช่วยให้คุณสามารถสร้างอิมเมจ Docker ซึ่งเป็นแพลตฟอร์มที่เป็นที่รู้จักในอุตสาหกรรมสำหรับการพัฒนา จัดส่ง และเรียกใช้แอปพลิเคชันในคอนเทนเนอร์

นอกเหนือจากการสอนขั้นตอนที่จำเป็นในการย้ายจาก App Engine ไปยัง Cloud Run แล้ว คุณยังจะได้เรียนรู้วิธีอัปเกรดแอป Java 8 App Engine เป็น Java 17

หากแอปพลิเคชันของคุณใช้งานบริการแบบกลุ่มเดิมของ App Engine หรือฟีเจอร์อื่นๆ ของ App Engine เป็นจำนวนมาก เราขอแนะนำให้ย้ายข้อมูลออกจากบริการที่รวมอยู่ในแพ็กเกจเหล่านั้นหรือแทนที่ฟีเจอร์เหล่านั้นก่อนที่จะย้ายไปยัง Cloud Run หากต้องการเวลาเพิ่มเติมในการตรวจสอบตัวเลือกการย้ายข้อมูล หรือต้องการใช้บริการที่รวมอยู่ในแพ็กเกจแบบเดิมต่อไปในขณะนี้ คุณจะเข้าถึงบริการแบบรวมของ App Engine สำหรับ Java 11/17 ต่อไปได้เมื่ออัปเกรดเป็นรันไทม์ที่ใหม่กว่า เมื่อแอปพกพาสะดวกมากขึ้น ให้กลับมาที่ Codelab นี้เพื่อดูวิธีใช้วิธีการกับแอปของคุณ

คุณจะได้เรียนรู้วิธีต่อไปนี้

  • ใช้ Cloud Shell
  • เปิดใช้ Cloud Run, Artifact Registry และ Cloud Build API
  • สร้างคอนเทนเนอร์ให้กับแอปโดยใช้ Jib และ Cloud Build
  • ทำให้อิมเมจคอนเทนเนอร์ใช้งานได้กับ Cloud Run

สิ่งที่คุณต้องมี

แบบสำรวจ

คุณจะใช้บทแนะนำนี้อย่างไร

อ่านเท่านั้น อ่านและทำแบบฝึกหัด

คุณจะให้คะแนนประสบการณ์การใช้งาน Java อย่างไร

มือใหม่ ระดับกลาง ผู้ชำนาญ

คุณจะให้คะแนนความพึงพอใจในการใช้บริการ Google Cloud อย่างไร

มือใหม่ ระดับกลาง ผู้ชำนาญ

2. ที่มา

ระบบ Platform as a Service (PaaS) อย่าง App Engine และ Cloud Functions ให้ความสะดวกมากมายแก่ทีมและแอปพลิเคชันของคุณ เช่น การทำให้ SysAdmins และ Devops สามารถมุ่งเน้นไปที่การสร้างโซลูชันได้ ด้วยแพลตฟอร์มที่ไม่จำกัด แอปของคุณสามารถปรับขนาดอัตโนมัติได้ตามต้องการ ลดขนาดเป็น 0 ด้วยการเรียกเก็บเงินแบบจ่ายต่อการใช้งานเพื่อช่วยควบคุมต้นทุน และใช้ภาษาในการพัฒนาทั่วไปที่หลากหลาย

อย่างไรก็ตาม ความยืดหยุ่นของคอนเทนเนอร์ก็น่าสนใจเช่นกัน คอนเทนเนอร์มีความสามารถในการเลือกภาษา ไลบรารี และไบนารีใดก็ได้ คุณจึงได้รับประโยชน์สูงสุดจากทั้ง 2 ด้าน ซึ่งก็คือความสะดวกสบายในการใช้งานแบบ Serverless และความยืดหยุ่นของคอนเทนเนอร์ นี่คือข้อมูลเกี่ยวกับ Cloud Run

การเรียนรู้วิธีใช้ Cloud Run ไม่ได้อยู่ในขอบเขตของ Codelab นี้ ที่อยู่ในเอกสารประกอบเกี่ยวกับ Cloud Run เป้าหมายนี้มีไว้เพื่อให้คุณทำความคุ้นเคยกับวิธีสร้างคอนเทนเนอร์แอป App Engine สำหรับ Cloud Run (หรือบริการอื่นๆ ที่โฮสต์บนคอนเทนเนอร์) มี 2-3 อย่างที่คุณควรทราบก่อนที่จะดำเนินการต่อ หลักๆ แล้วประสบการณ์ของผู้ใช้ของคุณจะแตกต่างออกไปเล็กน้อย

ใน Codelab นี้ คุณจะได้เรียนรู้วิธีการสร้างและทำให้คอนเทนเนอร์ใช้งานได้ โดยคุณจะได้เรียนรู้วิธีต่อไปนี้

  • สร้างคอนเทนเนอร์ด้วย Jib
  • ย้ายข้อมูลออกจากการกำหนดค่า App Engine
  • และกำหนดขั้นตอนบิลด์สำหรับ Cloud Build หรือไม่ก็ได้

ซึ่งรวมถึงการย้ายออกจากฟีเจอร์บางอย่างของ App Engine หากคุณไม่ต้องการปฏิบัติตามเส้นทางนี้ คุณยังคงอัปเกรดเป็นรันไทม์ Java 11/17 ได้ในขณะที่เก็บแอปไว้ใน App Engine แทน

3. การตั้งค่า/งานล่วงหน้า

1. สร้างโปรเจ็กต์

ในบทแนะนำนี้ คุณจะใช้แอปตัวอย่างจากที่เก็บ appengine-java-migration-samples ในโปรเจ็กต์ใหม่ ตรวจสอบว่าโปรเจ็กต์มีบัญชีสำหรับการเรียกเก็บเงินที่ใช้งานอยู่

หากคุณตั้งใจที่จะย้ายแอป App Engine ที่มีอยู่ไปยัง Cloud Run คุณสามารถใช้แอปดังกล่าวเพื่อติดตามเนื้อหาแทนได้

เรียกใช้คำสั่งต่อไปนี้เพื่อเปิดใช้ API ที่จำเป็นสำหรับโปรเจ็กต์ของคุณ

gcloud services enable artifactregistry.googleapis.com cloudbuild.googleapis.com run.googleapis.com

2. รับแอปตัวอย่างพื้นฐาน

โคลนแอปตัวอย่างในเครื่องของคุณเองหรือใน Cloud Shell จากนั้นไปที่โฟลเดอร์พื้นฐาน

ตัวอย่างนี้เป็นแอป Datastore แบบ Java 8 แบบ Servlet ที่มีไว้เพื่อทำให้ใช้งานได้ใน App Engine ทำตามวิธีการใน README เกี่ยวกับวิธีเตรียมแอปนี้สำหรับการทำให้ App Engine ใช้งานได้

3. (ไม่บังคับ) ทำให้แอปพื้นฐานใช้งานได้

ข้อมูลต่อไปนี้มีความจำเป็นเฉพาะเมื่อคุณต้องการยืนยันว่าแอปทำงานได้บน App Engine ก่อนที่เราจะย้ายข้อมูลไปยัง Cloud Run เท่านั้น

โปรดดูขั้นตอนใน README.md

  1. ติดตั้ง/ทำความคุ้นเคยกับ gcloud CLI
  2. เริ่มต้น gcloud CLI สำหรับโปรเจ็กต์ของคุณด้วย gcloud init
  3. สร้างโปรเจ็กต์ App Engine ด้วย gcloud app create
  4. ทำให้แอปตัวอย่างใช้งานได้กับ App Engine
./mvnw package appengine:deploy -Dapp.projectId=$PROJECT_ID
  1. ยืนยันว่าแอปทำงานบน App Engine ได้โดยไม่มีปัญหา

4. สร้างที่เก็บ Artifact Registry

หลังจากสร้างคอนเทนเนอร์แอปแล้ว จะต้องมีพื้นที่สำหรับพุชและจัดเก็บรูปภาพ วิธีที่แนะนำในการจัดการกับเรื่องนี้บน Google Cloud คือการใช้ Artifact Registry

สร้างที่เก็บชื่อ migration ด้วย gcloud ดังนี้

gcloud artifacts repositories create migration --repository-format=docker \
--description="Docker repository for the migrated app" \
--location="northamerica-northeast1"

โปรดทราบว่าที่เก็บนี้ใช้ประเภทรูปแบบ docker แต่มีประเภทที่เก็บหลายประเภท

เมื่อถึงจุดนี้ คุณก็มีแอป App Engine พื้นฐาน และโปรเจ็กต์ Google Cloud ของคุณก็พร้อมที่จะย้ายข้อมูลไปยัง Cloud Run แล้ว

4. แก้ไขไฟล์แอปพลิเคชัน

ในกรณีที่แอปของคุณใช้งานบริการที่รวมอยู่ในแพ็กเกจ การกำหนดค่า หรือฟีเจอร์อื่นๆ ของ App Engine แบบเดิมมากเกินไป เราขอแนะนำให้เข้าถึงบริการเหล่านั้นต่อไปขณะที่อัปเกรดเป็นรันไทม์ใหม่ Codelab นี้จะสาธิตเส้นทางการย้ายข้อมูลสำหรับแอปพลิเคชันที่ใช้บริการแบบสแตนด์อโลนอยู่แล้ว หรืออาจเปลี่ยนโครงสร้างภายในโค้ดเพื่อดำเนินการดังกล่าวได้

1. การอัปเกรดเป็น Java 17

หากแอปของคุณใช้ Java 8 ให้ลองอัปเกรดเป็นตัวเลือก LTS รุ่นที่ใหม่กว่า เช่น 11 หรือ 17 เพื่อไม่ให้พลาดการอัปเดตความปลอดภัยและเข้าถึงฟีเจอร์ภาษาใหม่ๆ

เริ่มต้นโดยการอัปเดตพร็อพเพอร์ตี้ใน pom.xml ให้รวมข้อมูลต่อไปนี้

<properties>
    <java.version>17</java.version>
    <maven.compiler.source>17</maven.compiler.source>
    <maven.compiler.target>17</maven.compiler.target>
</properties>

การดำเนินการนี้จะตั้งค่าเวอร์ชันของโปรเจ็กต์เป็น 17 ให้แจ้งปลั๊กอินคอมไพเลอร์ว่าคุณต้องการเข้าถึงฟีเจอร์ภาษา Java 17 และต้องการให้คลาสที่คอมไพล์ดังกล่าวใช้งานได้กับ Java 17 JVM

2. มีเว็บเซิร์ฟเวอร์

App Engine และ Cloud Run มีความแตกต่างกันหลายอย่างที่ควรพิจารณาเมื่อย้ายระหว่าง App Engine กับ Cloud Run ความแตกต่างอย่างหนึ่งคือขณะที่รันไทม์ Java 8 ของ App Engine จัดหาและจัดการเซิร์ฟเวอร์ Jetty สำหรับแอปที่โฮสต์นั้น Cloud Run ไม่ได้ทำเช่นนั้น เราจะใช้ Spring Boot ในการจัดเตรียมเว็บเซิร์ฟเวอร์และคอนเทนเนอร์ของเซิร์ฟเล็ต

เพิ่มทรัพยากร Dependency ต่อไปนี้

<dependencies>
<!-- ... -->
   <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-web</artifactId>
       <version>2.6.6</version>
       <exclusions>
           <!-- Exclude the Tomcat dependency -->
           <exclusion>
               <groupId>org.springframework.boot</groupId>
               <artifactId>spring-boot-starter-tomcat</artifactId>
           </exclusion>
       </exclusions>
   </dependency>
   <!-- Use Jetty instead -->
   <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-jetty</artifactId>
       <version>2.6.6</version>
   </dependency>
<!-- ... -->
</dependencies>

Spring Boot จะฝังเซิร์ฟเวอร์ Tomcat เป็นค่าเริ่มต้น แต่ตัวอย่างนี้จะยกเว้นอาร์ติแฟกต์นั้นและใช้กับ Jetty เพื่อลดความแตกต่างของลักษณะการทำงานเริ่มต้นหลังจากการย้ายข้อมูล นอกจากนี้เรายังกำหนดค่าเวอร์ชัน Jetty ให้จับคู่กับเวอร์ชันใน App Engine ที่มีให้ได้ทันที

<properties>
    <java.version>17</java.version>
    <maven.compiler.source>17</maven.compiler.source>
    <maven.compiler.target>17</maven.compiler.target>
    <jetty.version>9.4.46.v20220331</jetty.version>
</properties>

3. การตั้งค่าเปิดเครื่องฤดูใบไม้ผลิ

แม้ว่า Spring Boot จะใช้เซิร์ฟเล็ตซ้ำได้โดยไม่ต้องแก้ไข แต่จะต้องมีการกำหนดค่าบางอย่างเพื่อให้ค้นพบได้

สร้างคลาส MigratedServletApplication.java ต่อไปนี้ในแพ็กเกจ com.example.appengine

package com.example.appengine;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.EnableAutoConfiguration;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.web.servlet.ServletComponentScan;

@ServletComponentScan
@SpringBootApplication
@EnableAutoConfiguration
public class MigratedServletApplication {
    public static void main(String[] args) {
        SpringApplication.run(MigratedServletApplication.class, args);
    }
}

โปรดทราบว่าส่วนนี้รวมถึงคำอธิบายประกอบ @ServletComponentScan ซึ่งจะมีลักษณะ (ในแพ็กเกจปัจจุบันโดยค่าเริ่มต้น) สำหรับ @WebServlets ทั้งหมดและทำให้พร้อมใช้งานตามที่คาดไว้

4. จัดแพ็กเกจแอปเป็น JAR

แม้ว่าการเปลี่ยนแปลงแอปจะเป็นคอนเทนเนอร์ได้ด้วย Jib นับตั้งแต่สงคราม แต่จะง่ายขึ้นหากคุณจัดแพ็กเกจแอปเป็น JAR ที่สั่งการได้ ซึ่งไม่จำเป็นต้องใช้การกำหนดค่ามากนัก โดยเฉพาะสำหรับโปรเจ็กต์ที่ใช้ Maven เป็นเครื่องมือบิลด์ เนื่องจากบรรจุภัณฑ์แบบ Jar เป็นลักษณะการทำงานเริ่มต้น

นำแท็ก packaging ในไฟล์ pom.xml ออก:

<packaging>war</packaging>

จากนั้นเพิ่ม spring-boot-maven-plugin:

<plugins>
<!-- ... -->
  <plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <version>2.6.6</version>
  </plugin>
<!-- ... -->
</plugins>

5. การย้ายข้อมูลจากการกำหนดค่า บริการ และทรัพยากร Dependency ของ App Engine

ดังที่กล่าวในตอนต้นของ Codelab ว่า Cloud Run และ App Engine ได้รับการออกแบบมาเพื่อมอบประสบการณ์ที่แตกต่างกันให้กับผู้ใช้ ฟีเจอร์บางอย่างที่ App Engine มอบให้ให้ใช้งานได้ทันที เช่น บริการ Cron และ Task Queue จะต้องสร้างใหม่ด้วยตนเอง โดยจะอธิบายรายละเอียดเพิ่มเติมในโมดูลต่อๆ ไป

แอปตัวอย่างไม่ได้ใช้ประโยชน์จากบริการแบบแพ็กเกจแบบเดิม แต่ผู้ใช้ที่มีแอปจะสามารถดูคำแนะนำต่อไปนี้

เนื่องจากคุณจะทำให้ใช้งานได้กับ Cloud Run นับจากนี้ไป คุณจึงสามารถนำ appengine-maven-plugin ออกได้

<plugin>
 <groupId>com.google.cloud.tools</groupId>
 <artifactId>appengine-maven-plugin</artifactId>
 <version>2.4.1</version>
 <configuration>
   <!-- can be set w/ -DprojectId=myProjectId on command line -->
   <projectId>${app.projectId}</projectId>
   <!-- set the GAE version or use "GCLOUD_CONFIG" for an autogenerated GAE version -->
   <version>GCLOUD_CONFIG</version>
 </configuration>
</plugin>

5. แอปพลิเคชัน Containerize

ในจุดนี้ คุณสามารถทำให้แอปใช้งานได้กับ Cloud Run โดยตรงจากซอร์สโค้ด เวอร์ชันนี้เป็นตัวเลือกที่ยอดเยี่ยมที่ใช้ Cloud Build อยู่เบื้องหลังเพื่อมอบประสบการณ์การติดตั้งใช้งานโดยไม่ต้องสัมผัส เราจะอธิบายการใช้งานต้นฉบับอย่างละเอียดยิ่งขึ้นในโมดูลต่อๆ ไป

หรือหากต้องการควบคุมวิธีทำให้แอปใช้งานได้มากขึ้น ก็ทำได้โดยการกำหนดไฟล์ cloudbuild.yaml ที่แสดงขั้นตอนบิลด์ที่คุณต้องการอย่างชัดเจน

1. กำหนดไฟล์ cloudbuild.yaml

สร้างไฟล์ cloudbuild.yaml ต่อไปนี้ที่ระดับเดียวกับ pom.xml

steps:
  # Test your build
  - name: maven:eclipse-temurin
    entrypoint: mvn
    args: ["test"]
  # Build with Jib
  - name: maven:eclipse-temurin
    entrypoint: mvn
    args: [ "compile", "com.google.cloud.tools:jib-maven-plugin:3.2.1:build", "-Dimage=northamerica-northeast1-docker.pkg.dev/PROJECT_ID/migration/visitors:jib"]
  # Deploy to Cloud Run
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: gcloud
    args: [ 'run', 'deploy', 'visitors', '--image', 'northamerica-northeast1-docker.pkg.dev/PROJECT_ID/migration/visitors:jib', '--region', 'northamerica-northeast1', '--allow-unauthenticated']

เมื่อเราบอกให้ Cloud Build ทำตามขั้นตอนเหล่านี้ ระบบจะดำเนินการต่อไปนี้

  1. ทำการทดสอบด้วย ./mvnw test
  2. สร้าง พุช และติดแท็กรูปภาพไปยัง Artifact Registry ด้วย Jib
  3. ทำให้อิมเมจของคุณใช้งานได้ใน Cloud Run ด้วย gcloud run deploy

โปรดทราบว่ามีการระบุ ‘visitors' ให้กับ Cloud Run เป็นชื่อบริการที่ต้องการ แฟล็ก –allow-unauthenticated ช่วยให้ผู้ใช้เข้าชมเว็บแอปได้โดยไม่ต้องตรวจสอบสิทธิ์ อย่าลืมแทนที่ PROJECT_ID ด้วยรหัสของโครงการในไฟล์ cloudbuild.yaml

ถัดไป ให้เพิ่มการเชื่อมโยงนโยบาย IAM ต่อไปนี้เพื่ออนุญาตให้บัญชีบริการ Cloud Build กับ Artifact Registry

export PROJECT_ID=$(gcloud config list --format 'value(core.project)')
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)" )

gcloud projects add-iam-policy-binding $PROJECT_ID \
--member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
--role=roles/run.admin \
--project=$PROJECT_ID
gcloud iam service-accounts add-iam-policy-binding $PROJECT_NUMBER-compute@developer.gserviceaccount.com \
--member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
--role roles/iam.serviceAccountUser --project=$PROJECT_ID

2. เรียกใช้กระบวนการบิลด์

เมื่อแจ้ง Cloud Build เกี่ยวกับขั้นตอนบิลด์ที่ต้องการแล้ว คุณก็พร้อมติดตั้งใช้งานได้ในคลิกเดียว

เรียกใช้คำสั่งต่อไปนี้

gcloud builds submit

เมื่อกระบวนการเสร็จสิ้นแล้ว ระบบจะสร้างอิมเมจคอนเทนเนอร์ขึ้น จัดเก็บไว้ใน Artifact Registry และทำให้ใช้งานได้กับ Cloud Run แล้ว

ในตอนท้ายของ Codelab นี้ แอปของคุณควรมีลักษณะเดียวกับแอปใน java17-and-cloud-run/finish

เพียงเท่านี้ก็เรียบร้อยแล้ว คุณย้ายข้อมูลแอป Java 8 App Engine ไปยัง Java 17 และ Cloud Run สำเร็จแล้ว และตอนนี้มีความเข้าใจที่ชัดเจนยิ่งขึ้นเกี่ยวกับงานที่เกี่ยวข้องเมื่อสลับและเลือกตัวเลือกโฮสติ้ง

6. สรุป/ล้างข้อมูล

ขอแสดงความยินดี คุณได้อัปเกรด สร้างคอนเทนเนอร์ ย้ายข้อมูล และย้ายข้อมูลแอปแล้ว ซึ่งได้จบบทแนะนำนี้

ขั้นตอนถัดไปคือการศึกษาข้อมูลเพิ่มเติมเกี่ยวกับฟีเจอร์ CI/CD และซัพพลายเชนของซอฟต์แวร์ที่เข้าถึงได้แล้วตอนนี้ซึ่งทำให้ใช้งานได้ด้วย Cloud Build แล้ว

ไม่บังคับ: ล้างข้อมูลและ/หรือปิดใช้บริการ

หากคุณทำให้แอปตัวอย่างใช้งานได้ใน App Engine ระหว่างบทแนะนำนี้ อย่าลืมปิดใช้แอปเพื่อหลีกเลี่ยงการเรียกเก็บเงิน เมื่อพร้อมที่จะย้ายไปยัง Codelab ถัดไปแล้ว คุณก็เปิดใช้อีกครั้งได้ ในขณะที่แอป App Engine ปิดใช้อยู่ แอปเหล่านี้จะไม่ได้รับการเข้าชมใดๆ ที่มีค่าใช้จ่าย อย่างไรก็ตาม การใช้ Datastore อาจเรียกเก็บเงินได้หากเกินโควต้าฟรี ดังนั้นโปรดลบออกให้ไม่เกินจำนวนที่จำกัดไว้

ในทางกลับกัน หากไม่ต้องการย้ายข้อมูลต่อและต้องการลบทุกอย่างออกอย่างสมบูรณ์ คุณสามารถลบบริการหรือปิดโปรเจ็กต์ทั้งหมด

7. แหล่งข้อมูลเพิ่มเติม

ปัญหา/ข้อเสนอแนะเกี่ยวกับ Codelab ของโมดูลการย้ายข้อมูล App Engine

หากมีปัญหาใดๆ เกี่ยวกับ Codelab นี้ โปรดค้นหาปัญหาของคุณก่อนยื่น ลิงก์สำหรับค้นหาและสร้างปัญหาใหม่

แหล่งข้อมูลสำหรับการย้ายข้อมูล

แหล่งข้อมูลออนไลน์

ด้านล่างนี้คือแหล่งข้อมูลออนไลน์ที่อาจเกี่ยวข้องกับบทแนะนำนี้

App Engine

ข้อมูลอื่นๆ เกี่ยวกับระบบคลาวด์

วิดีโอ

ใบอนุญาต

ผลงานนี้ได้รับอนุญาตภายใต้ใบอนุญาตทั่วไปครีเอทีฟคอมมอนส์แบบระบุแหล่งที่มา 2.0