Google ক্লাউডে বসন্ত নেটিভ

১. সংক্ষিপ্ত বিবরণ

এই কোডল্যাবে আমরা স্প্রিং নেটিভ প্রজেক্ট সম্পর্কে জানব, এটি ব্যবহার করে একটি অ্যাপ তৈরি করব এবং গুগল ক্লাউডে তা ডেপ্লয় করব।

আমরা এর উপাদানসমূহ, প্রকল্পটির সাম্প্রতিক ইতিহাস, এর কিছু ব্যবহারিক উদাহরণ এবং অবশ্যই আপনার প্রকল্পে এটি ব্যবহার করার জন্য প্রয়োজনীয় পদক্ষেপগুলো নিয়ে আলোচনা করব।

Spring Native প্রজেক্টটি বর্তমানে একটি পরীক্ষামূলক পর্যায়ে রয়েছে, তাই এটি শুরু করার জন্য কিছু নির্দিষ্ট কনফিগারেশনের প্রয়োজন হবে। তবে, SpringOne 2021-এ ঘোষিত ঘোষণা অনুযায়ী, Spring Native-কে Spring Framework 6.0 এবং Spring Boot 3.0-এর সাথে ফার্স্ট ক্লাস সাপোর্টসহ ইন্টিগ্রেট করা হবে। সুতরাং, এর রিলিজের কয়েক মাস আগে প্রজেক্টটি ভালোভাবে খতিয়ে দেখার জন্য এটাই উপযুক্ত সময়।

যদিও জাস্ট-ইন-টাইম কম্পাইলেশন দীর্ঘক্ষণ ধরে চলা প্রসেসগুলোর মতো বিষয়গুলোর জন্য খুব ভালোভাবে অপ্টিমাইজ করা হয়েছে, তবুও কিছু নির্দিষ্ট ব্যবহারের ক্ষেত্র রয়েছে যেখানে অ্যাহেড-অফ-টাইম কম্পাইল করা অ্যাপ্লিকেশনগুলো আরও ভালো পারফর্ম করে, যা নিয়ে আমরা কোডল্যাবে আলোচনা করব।

আপনি শিখবেন কিভাবে

• ক্লাউড শেল ব্যবহার করুন
• ক্লাউড রান এপিআই সক্রিয় করুন
• একটি Spring Native অ্যাপ তৈরি এবং স্থাপন করুন
• ক্লাউড রানে এই ধরনের একটি অ্যাপ স্থাপন করুন

আপনার যা যা লাগবে

• একটি সক্রিয় GCP বিলিং অ্যাকাউন্ট সহ একটি গুগল ক্লাউড প্ল্যাটফর্ম প্রজেক্ট
• gcloud cli ইনস্টল করা আছে, অথবা ক্লাউড শেলে অ্যাক্সেস আছে
• বেসিক জাভা + এক্সএমএল দক্ষতা
• সাধারণ লিনাক্স কমান্ড সম্পর্কে কার্যকরী জ্ঞান

জরিপ

আপনি এই টিউটোরিয়ালটি কীভাবে ব্যবহার করবেন?

শুধু পুরোটা পড়ুন এটি পড়ুন এবং অনুশীলনগুলো সম্পূর্ণ করুন।

জাভা নিয়ে আপনার অভিজ্ঞতাকে আপনি কীভাবে মূল্যায়ন করবেন?

শিক্ষানবিশ মধ্যবর্তী দক্ষ

গুগল ক্লাউড পরিষেবা ব্যবহারের অভিজ্ঞতাকে আপনি কীভাবে মূল্যায়ন করবেন?

শিক্ষানবিশ মধ্যবর্তী দক্ষ

২. পটভূমি

স্প্রিং নেটিভ প্রজেক্টটি ডেভেলপারদের কাছে নেটিভ অ্যাপ্লিকেশনের পারফরম্যান্স পৌঁছে দিতে বিভিন্ন প্রযুক্তি ব্যবহার করে।

Spring Native সম্পূর্ণরূপে বোঝার জন্য, এর কয়েকটি উপাদান প্রযুক্তি, সেগুলো আমাদের কী সুবিধা দেয় এবং এখানে কীভাবে একসাথে কাজ করে, তা বোঝা সহায়ক।

AOT সংকলন

যখন ডেভেলপাররা কম্পাইল করার সময় স্বাভাবিকভাবে javac চালান, তখন আমাদের .java সোর্স কোড কম্পাইল হয়ে .class ফাইলে পরিণত হয়, যা বাইটকোডে লেখা থাকে। এই বাইটকোডটি শুধুমাত্র জাভা ভার্চুয়াল মেশিন (JVM) বোঝার জন্য তৈরি, তাই আমাদের কোড চালানোর জন্য অন্যান্য মেশিনে JVM-কে এই কোডটি ইন্টারপ্রেট করতে হয়।

এই প্রক্রিয়াটিই আমাদেরকে জাভার সিগনেচার পোর্টেবিলিটি প্রদান করে – যা আমাদেরকে ‘একবার লিখে সব জায়গায় চালানোর’ সুযোগ দেয়, কিন্তু নেটিভ কোড চালানোর তুলনায় এটি ব্যয়বহুল।

সৌভাগ্যবশত, JVM-এর বেশিরভাগ ইমপ্লিমেন্টেশন এই ইন্টারপ্রিটেশন খরচ কমানোর জন্য জাস্ট-ইন-টাইম কম্পাইলেশন ব্যবহার করে। এটি করা হয় একটি ফাংশনের ইনভোকেশন গণনা করার মাধ্যমে, এবং যদি এটি একটি নির্দিষ্ট সীমা ( ডিফল্টরূপে ১০,০০০ ) অতিক্রম করার মতো যথেষ্টবার ইনভোক করা হয়, তবে পরবর্তী ব্যয়বহুল ইন্টারপ্রিটেশন এড়ানোর জন্য রান টাইমে এটিকে নেটিভ কোডে কম্পাইল করা হয়।

অ্যাহেড-অফ-টাইম কম্পাইলেশন এর বিপরীত পদ্ধতি অবলম্বন করে, যেখানে কম্পাইল করার সময়েই অ্যাক্সেসযোগ্য সমস্ত কোডকে একটি নেটিভ এক্সিকিউটেবলে কম্পাইল করা হয়। এর ফলে পোর্টেবিলিটির বিনিময়ে রান টাইমে মেমরি দক্ষতা এবং অন্যান্য পারফরম্যান্স সুবিধা পাওয়া যায়।

অবশ্যই, এটি একটি আপস, এবং সবসময় তা গ্রহণ করা যুক্তিযুক্ত নয়। তবে, কিছু নির্দিষ্ট ক্ষেত্রে AOT কম্পাইলেশন বিশেষভাবে কার্যকর হতে পারে, যেমন:

• স্বল্পস্থায়ী অ্যাপ্লিকেশন যেখানে স্টার্টআপ সময় গুরুত্বপূর্ণ
• অত্যন্ত সীমিত মেমরির পরিবেশ যেখানে JIT খুব ব্যয়বহুল হতে পারে

একটি মজার তথ্য হলো, AOT কম্পাইলেশন JDK 9-এ একটি পরীক্ষামূলক ফিচার হিসেবে চালু করা হয়েছিল। তবে এই ইমপ্লিমেন্টেশনটির রক্ষণাবেক্ষণ ব্যয়বহুল ছিল এবং এটি তেমন জনপ্রিয়তা পায়নি, তাই ডেভেলপারদের GraalVM ব্যবহারের সুবিধার জন্য Java 17-এ এটিকে নীরবে সরিয়ে দেওয়া হয়।

গ্রালভিএম

GraalVM হলো একটি অত্যন্ত অপ্টিমাইজড ওপেন সোর্স JDK ডিস্ট্রিবিউশন, যার রয়েছে অত্যন্ত দ্রুত স্টার্টআপ টাইম, AOT নেটিভ ইমেজ কম্পাইলেশন এবং পলিগ্লট সক্ষমতা, যা ডেভেলপারদের একটি অ্যাপ্লিকেশনে একাধিক ভাষা মিশ্রিত করার সুযোগ দেয়।

GraalVM-এর সক্রিয় উন্নয়ন চলছে এবং এটি প্রতিনিয়ত নতুন সক্ষমতা অর্জন ও বিদ্যমানগুলোর উন্নতি সাধন করছে, তাই আমি ডেভেলপারদের এর সাথে যুক্ত থাকার জন্য উৎসাহিত করছি।

সাম্প্রতিক কিছু উল্লেখযোগ্য মাইলফলক হলো:

• একটি নতুন, ব্যবহারকারী-বান্ধব নেটিভ ইমেজ বিল্ড আউটপুট ( ২০২১-০১-১৮ )
• জাভা ১৭ সমর্থন ( ২০২২-০১-১৮ )
• পলিগ্লট কম্পাইলের সময় উন্নত করতে ডিফল্টরূপে মাল্টি-টিয়ার কম্পাইলেশন সক্রিয় করা হচ্ছে ( ২০২১-০৪-২০ )

বসন্তের স্থানীয়

সহজ কথায় বলতে গেলে - Spring Native, GraalVM-এর নেটিভ-ইমেজ কম্পাইলার ব্যবহার করে Spring অ্যাপ্লিকেশনগুলোকে নেটিভ এক্সিকিউটেবলে পরিণত করতে সক্ষম করে।

এই প্রক্রিয়ার আওতায় কম্পাইল টাইমে আপনার অ্যাপ্লিকেশনের একটি স্ট্যাটিক বিশ্লেষণ করা হয়, যার মাধ্যমে এন্ট্রি পয়েন্ট থেকে অ্যাক্সেসযোগ্য সমস্ত মেথড খুঁজে বের করা হয়।

এটি মূলত আপনার অ্যাপ্লিকেশনের একটি "ক্লোজড-ওয়ার্ল্ড" ধারণা তৈরি করে, যেখানে ধরে নেওয়া হয় যে কম্পাইল টাইমে সমস্ত কোড জানা থাকে এবং রানটাইমে কোনো নতুন কোড লোড করার অনুমতি নেই।

এটা মনে রাখা গুরুত্বপূর্ণ যে, নেটিভ ইমেজ তৈরি করা একটি মেমরি-নিবিড় প্রক্রিয়া, যা একটি সাধারণ অ্যাপ্লিকেশন কম্পাইল করার চেয়ে বেশি সময় নেয় এবং জাভার কিছু নির্দিষ্ট দিকের উপর সীমাবদ্ধতা আরোপ করে।

কিছু ক্ষেত্রে, Spring Native-এর সাথে কোনো অ্যাপ্লিকেশন কাজ করানোর জন্য কোডে কোনো পরিবর্তনের প্রয়োজন হয় না। তবে, কিছু পরিস্থিতিতে সঠিকভাবে কাজ করার জন্য নির্দিষ্ট নেটিভ কনফিগারেশনের প্রয়োজন হয়। সেইসব ক্ষেত্রে, Spring Native প্রায়শই এই প্রক্রিয়াটিকে সহজ করার জন্য Native Hints প্রদান করে থাকে।

৩. প্রস্তুতি/পূর্বপ্রস্তুতি

Spring Native প্রয়োগ শুরু করার আগে, আমাদের অ্যাপটি তৈরি ও ডেপ্লয় করতে হবে, যাতে একটি পারফরম্যান্স বেসলাইন স্থাপন করা যায়, যা আমরা পরে নেটিভ সংস্করণের সাথে তুলনা করতে পারব।

১. প্রকল্পটি তৈরি করা

আমরা start.spring.io থেকে আমাদের অ্যাপটি নিয়ে কাজ শুরু করব:

curl https://start.spring.io/starter.zip -d dependencies=web \
           -d javaVersion=11 \
           -d bootVersion=2.6.4 -o io-native-starter.zip

এই স্টার্টার অ্যাপটিতে স্প্রিং বুট ২.৬.৪ ব্যবহার করা হয়েছে, যা এই লেখাটির সময়ে স্প্রিং-নেটিভ প্রজেক্টের সমর্থিত সর্বশেষ সংস্করণ।

উল্লেখ্য যে, GraalVM 21.0.3 প্রকাশের পর থেকে আপনি এই স্যাম্পলটির জন্য জাভা ১৭-ও ব্যবহার করতে পারবেন। কনফিগারেশন ন্যূনতম রাখার জন্য আমরা এই টিউটোরিয়ালে জাভা ১১-ই ব্যবহার করব।

কমান্ড লাইনে আমাদের জিপ ফাইলটি চলে আসার পর, আমরা আমাদের প্রোজেক্টের জন্য একটি সাবডিরেক্টরি তৈরি করে সেখানে ফোল্ডারটি আনজিপ করতে পারি:

mkdir spring-native

cd spring-native

unzip ../io-native-starter.zip

২. কোড পরিবর্তন

প্রজেক্টটি চালু হয়ে গেলেই আমরা দ্রুত এতে প্রাণের সঞ্চার করব এবং স্প্রিং নেটিভ পারফরম্যান্সটি চালানোর পর তা প্রদর্শন করব।

DemoApplication.java ফাইলটি নিম্নরূপে সম্পাদনা করুন:

package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.context.event.ApplicationReadyEvent;
import org.springframework.context.event.EventListener;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

import java.time.Duration;
import java.time.Instant;

@RestController
@SpringBootApplication
public class DemoApplication {
    private static Instant startTime;
    private static Instant readyTime;

    public static void main(String[] args) {
        startTime = Instant.now();
                SpringApplication.run(DemoApplication.class, args);
    }

    @GetMapping("/")
    public String index() {
        return "Time between start and ApplicationReadyEvent: "
                + Duration.between(startTime, readyTime).toMillis()
                + "ms";
    }

    @EventListener(ApplicationReadyEvent.class)
    public void ready() {
                readyTime = Instant.now();
    }
}

এই পর্যায়ে আমাদের বেসলাইন অ্যাপটি ব্যবহারের জন্য প্রস্তুত, তাই এটিকে নেটিভ অ্যাপ্লিকেশনে রূপান্তর করার আগে এর স্টার্টআপ টাইম সম্পর্কে ধারণা পেতে আপনি নির্দ্বিধায় একটি ইমেজ বিল্ড করে আপনার লোকাল মেশিনে রান করতে পারেন।

আমাদের ভাবমূর্তি গড়ে তুলতে:

mvn spring-boot:build-image

বেসলাইন ইমেজের আকার সম্পর্কে ধারণা পেতে আপনি docker images demo ব্যবহার করতে পারেন:

আমাদের অ্যাপটি চালাতে:

docker run --rm -p 8080:8080 demo:0.0.1-SNAPSHOT

৩. বেসলাইন অ্যাপ স্থাপন করুন

এখন যেহেতু আমাদের অ্যাপটি তৈরি হয়ে গেছে, আমরা এটি ডেপ্লয় করব এবং সময়গুলো লিখে রাখব, যা আমরা পরবর্তীতে আমাদের নেটিভ অ্যাপের স্টার্টআপ সময়ের সাথে তুলনা করব।

আপনি কী ধরনের অ্যাপ্লিকেশন তৈরি করছেন তার উপর নির্ভর করে আপনার ডেটা হোস্ট করার জন্য বিভিন্ন বিকল্প রয়েছে।

তবে, যেহেতু আমাদের উদাহরণটি একটি খুবই সহজ ও সরল ওয়েব অ্যাপ্লিকেশন, তাই আমরা বিষয়গুলো সহজ রাখতে পারি এবং ক্লাউড রানের ওপর নির্ভর করতে পারি।

আপনি যদি নিজের মেশিনে এটি অনুসরণ করেন, তাহলে নিশ্চিত হয়ে নিন যে আপনার gcloud CLI টুলটি ইনস্টল এবং আপডেট করা আছে।

আপনি যদি ক্লাউড শেলে থাকেন, তাহলে এই সবকিছুর ব্যবস্থা হয়ে যাবে এবং আপনি সোর্স ডিরেক্টরিতে শুধু নিম্নলিখিত কমান্ডটি চালাতে পারেন:

gcloud run deploy

৪. অ্যাপ্লিকেশন কনফিগারেশন

১. আমাদের মেভেন রিপোজিটরিগুলো কনফিগার করা

যেহেতু এই প্রকল্পটি এখনও পরীক্ষামূলক পর্যায়ে রয়েছে, তাই আমাদের অ্যাপটিকে এমনভাবে কনফিগার করতে হবে যাতে এটি পরীক্ষামূলক আর্টিফ্যাক্টগুলো খুঁজে পেতে পারে, যেগুলো মেভেনের কেন্দ্রীয় রিপোজিটরিতে উপলব্ধ নেই।

এর জন্য আমাদের pom.xml ফাইলে নিম্নলিখিত উপাদানগুলো যোগ করতে হবে, যা আপনি আপনার পছন্দের এডিটরে করতে পারেন।

আমাদের pom-এ নিম্নলিখিত repositories এবং pluginRepositories সেকশনগুলো যোগ করুন:

<repositories>
    <repository>
        <id>spring-release</id>
        <name>Spring release</name>
        <url>https://repo.spring.io/release</url>
    </repository>
</repositories>

<pluginRepositories>
    <pluginRepository>
        <id>spring-release</id>
        <name>Spring release</name>
        <url>https://repo.spring.io/release</url>
    </pluginRepository>
</pluginRepositories>

২. আমাদের নির্ভরতাগুলো যোগ করা

এরপরে, spring-native ডিপেন্ডেন্সিটি যোগ করুন, যা একটি Spring অ্যাপ্লিকেশনকে নেটিভ ইমেজ হিসেবে চালানোর জন্য প্রয়োজন। দ্রষ্টব্য: আপনি যদি Gradle ব্যবহার করেন তবে এই ধাপটি প্রয়োজনীয় নয়।

<dependencies>
    <!-- ... -->
    <dependency>
        <groupId>org.springframework.experimental</groupId>
        <artifactId>spring-native</artifactId>
        <version>0.11.2</version>
    </dependency>
</dependencies>

৩. আমাদের প্লাগইনগুলি যোগ করা/সক্রিয় করা

এখন নেটিভ ইমেজের সামঞ্জস্যতা এবং ফুটপ্রিন্ট উন্নত করতে AOT প্লাগইনটি যোগ করুন ( আরও পড়ুন ):

<plugins>
    <!-- ... -->
    <plugin>
        <groupId>org.springframework.experimental</groupId>
        <artifactId>spring-aot-maven-plugin</artifactId>
        <version>0.11.2</version>
        <executions>
            <execution>
                <id>generate</id>
                <goals>
                    <goal>generate</goal>
                </goals>
            </execution>
        </executions>
    </plugin>
</plugins>

এখন আমরা নেটিভ ইমেজ সাপোর্ট চালু করতে spring-boot-maven-plugin আপডেট করব এবং আমাদের নেটিভ ইমেজ বিল্ড করার জন্য paketo বিল্ডার ব্যবহার করব:

<plugins>
    <!-- ... -->
    <plugin>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-maven-plugin</artifactId>
        <configuration>
            <image>
                <builder>paketobuildpacks/builder:tiny</builder>
                <env>
                    <BP_NATIVE_IMAGE>true</BP_NATIVE_IMAGE>
                </env>
            </image>
        </configuration>
    </plugin>    
</plugins>

উল্লেখ্য যে, ক্ষুদ্র বিল্ডার ইমেজটি বেশ কয়েকটি বিকল্পের মধ্যে মাত্র একটি। আমাদের কাজের ক্ষেত্রে এটি একটি ভালো পছন্দ, কারণ এতে খুব কম অতিরিক্ত লাইব্রেরি ও ইউটিলিটি রয়েছে, যা আমাদের আক্রমণের ক্ষেত্রকে সীমিত করতে সাহায্য করে।

উদাহরণস্বরূপ, আপনি যদি এমন একটি অ্যাপ তৈরি করেন যার কিছু সাধারণ C লাইব্রেরিতে অ্যাক্সেসের প্রয়োজন, অথবা আপনি যদি আপনার অ্যাপের প্রয়োজনীয়তা সম্পর্কে এখনও নিশ্চিত না হন, তাহলে ফুল-বিল্ডার আপনার জন্য আরও উপযুক্ত হতে পারে।

৫. নেটিভ অ্যাপ তৈরি ও রান করুন

একবার সবকিছু ঠিকঠাক হয়ে গেলে, আমরা আমাদের ইমেজ তৈরি করতে এবং আমাদের নেটিভ, কম্পাইল করা অ্যাপটি চালাতে সক্ষম হব।

বিল্ডটি চালানোর আগে, কয়েকটি বিষয় মনে রাখতে হবে:

• এতে সাধারণ বিল্ডের (কয়েক মিনিট) চেয়ে বেশি সময় লাগবে।
• এই বিল্ড প্রক্রিয়াটিতে অনেক মেমরি (কয়েক গিগাবাইট) লাগতে পারে।
• এই বিল্ড প্রক্রিয়ার জন্য ডকার ডেমনটি অ্যাক্সেসযোগ্য থাকা প্রয়োজন।
• যদিও এই উদাহরণে আমরা প্রক্রিয়াটি ম্যানুয়ালি করছি, আপনি আপনার বিল্ড ফেজগুলোকে এমনভাবে কনফিগার করতে পারেন যাতে এটি স্বয়ংক্রিয়ভাবে একটি নেটিভ বিল্ড প্রোফাইল চালু করে ।

আমাদের ভাবমূর্তি গড়ে তুলতে:

mvn spring-boot:build-image

সেটা তৈরি হয়ে গেলেই, আমরা নেটিভ অ্যাপটি বাস্তবে কাজ করতে দেখার জন্য প্রস্তুত!

আমাদের অ্যাপটি চালাতে:

docker run --rm -p 8080:8080 demo:0.0.1-SNAPSHOT

এই মুহূর্তে আমরা নেটিভ অ্যাপ্লিকেশন সমীকরণের উভয় দিক দেখার জন্য একটি চমৎকার অবস্থানে আছি।

কম্পাইল করার সময় আমরা কিছুটা সময় এবং অতিরিক্ত মেমরি ব্যবহার ত্যাগ করেছি, কিন্তু এর বিনিময়ে আমরা এমন একটি অ্যাপ্লিকেশন পেয়েছি যা অনেক দ্রুত চালু হতে পারে এবং (কাজের ধরনের ওপর নির্ভর করে) উল্লেখযোগ্যভাবে কম মেমরি ব্যবহার করে।

নেটিভ ইমেজের আকারের সাথে মূল ইমেজের আকার তুলনা করার জন্য যদি আমরা docker images demo চালাই, তাহলে আমরা একটি নাটকীয় হ্রাস দেখতে পাব:

আমাদের এটাও মনে রাখতে হবে যে, আরও জটিল ব্যবহারের ক্ষেত্রে, আপনার অ্যাপ রানটাইমে কী করবে তা AOT কম্পাইলারকে জানানোর জন্য অতিরিক্ত পরিবর্তনের প্রয়োজন হয়। সেই কারণে, কিছু অনুমানযোগ্য ওয়ার্কলোড (যেমন ব্যাচ জব) এর জন্য খুব উপযুক্ত হতে পারে, আবার অন্যগুলোর ক্ষেত্রে কাজটি আরও কঠিন হতে পারে।

৬. আমাদের নেটিভ অ্যাপ স্থাপন করা

ক্লাউড রান-এ আমাদের অ্যাপটি ডেপ্লয় করার জন্য, আর্টিফ্যাক্ট রেজিস্ট্রি-র মতো কোনো প্যাকেজ ম্যানেজারে আমাদের নেটিভ ইমেজটি যুক্ত করতে হবে।

১. আমাদের ডকার রিপোজিটরি প্রস্তুত করা

আমরা রিপোজিটরি তৈরি করার মাধ্যমে এই প্রক্রিয়াটি শুরু করতে পারি:

gcloud artifacts repositories create native-image-docker-repo --repository-format=docker \
--location=us-central1 --description="Repository for our native images"

এরপরে, আমাদের নতুন রেজিস্ট্রি-তে ডেটা পাঠানোর জন্য আমরা যে প্রমাণীকৃত, তা নিশ্চিত করতে হবে।

gcloud CLI সেই প্রক্রিয়াটিকে অনেকটাই সহজ করে দিতে পারে:

gcloud auth configure-docker us-central1-docker.pkg.dev

২. আর্টিফ্যাক্ট রেজিস্ট্রি-তে আমাদের ছবিটি অন্তর্ভুক্ত করা

এরপর আমরা আমাদের ছবিতে ট্যাগ যুক্ত করব:

export PROJECT_ID=$(gcloud config list --format 'value(core.project)')


docker tag  demo:0.0.1-SNAPSHOT \
us-central1-docker.pkg.dev/$PROJECT_ID/native-image-docker-repo/quickstart-image:tag2

এবং তারপরে আমরা docker push ব্যবহার করে এটিকে আর্টিফ্যাক্ট রেজিস্ট্রি-তে পাঠাতে পারি:

docker push us-central1-docker.pkg.dev/$PROJECT_ID/native-image-docker-repo/quickstart-image:tag2

৩. ক্লাউড রান-এ ডেপ্লয় করা

আমরা এখন আর্টিফ্যাক্ট রেজিস্ট্রি-তে সংরক্ষিত ইমেজটি ক্লাউড রান-এ ডেপ্লয় করার জন্য প্রস্তুত:

gcloud run deploy --image us-central1-docker.pkg.dev/$PROJECT_ID/native-image-docker-repo/quickstart-image:tag2

যেহেতু আমরা আমাদের অ্যাপটি একটি নেটিভ ইমেজ হিসেবে তৈরি ও স্থাপন করেছি, তাই আমরা নিশ্চিন্ত থাকতে পারি যে অ্যাপ্লিকেশনটি চলার সময় আমাদের অবকাঠামোগত খরচের চমৎকার সদ্ব্যবহার করছে।

আপনি আমাদের বেসলাইন অ্যাপের সাথে এই নতুন নেটিভ অ্যাপটির স্টার্টআপ টাইম নিজেই তুলনা করে দেখতে পারেন!

৭. সারসংক্ষেপ/পরিষ্কারকরণ

গুগল ক্লাউডে একটি স্প্রিং নেটিভ অ্যাপ্লিকেশন তৈরি এবং স্থাপন করার জন্য অভিনন্দন!

আশা করি এই টিউটোরিয়ালটি আপনাকে Spring Native প্রজেক্টের সাথে আরও পরিচিত হতে উৎসাহিত করবে এবং ভবিষ্যতে আপনার প্রয়োজন হলে এটি মনে রাখবেন।

ঐচ্ছিক: পরিষ্করণ করুন এবং/অথবা পরিষেবা নিষ্ক্রিয় করুন

আপনি এই কোডল্যাবের জন্য গুগল ক্লাউড প্রজেক্ট তৈরি করে থাকুন বা বিদ্যমান কোনো প্রজেক্ট পুনরায় ব্যবহার করুন, আমাদের ব্যবহৃত রিসোর্সগুলো থেকে যেন অপ্রয়োজনীয় চার্জ না হয়, সেদিকে খেয়াল রাখবেন।

আপনি আমাদের তৈরি করা ক্লাউড রান পরিষেবাগুলি মুছে ফেলতে বা নিষ্ক্রিয় করতে পারেন, আমাদের হোস্ট করা ইমেজটি মুছে ফেলতে পারেন, অথবা পুরো প্রকল্পটি বন্ধ করে দিতে পারেন ।

৮. অতিরিক্ত সম্পদ

যদিও স্প্রিং নেটিভ প্রকল্পটি বর্তমানে একটি নতুন এবং পরীক্ষামূলক প্রকল্প, তবুও প্রাথমিক ব্যবহারকারীদের সমস্যা সমাধানে এবং এতে যুক্ত হতে সাহায্য করার জন্য ইতিমধ্যেই প্রচুর ভালো রিসোর্স রয়েছে:

অতিরিক্ত সম্পদ

এই টিউটোরিয়ালটির জন্য প্রাসঙ্গিক হতে পারে এমন কিছু অনলাইন রিসোর্স নিচে দেওয়া হলো:

• নেটিভ হিন্টস সম্পর্কে আরও জানুন
• GraalVM সম্পর্কে আরও জানুন
• কীভাবে যুক্ত হবেন
• নেটিভ ইমেজ বিল্ড করার সময় মেমোরি শেষ হয়ে যাওয়ার ত্রুটি
• অ্যাপ্লিকেশন চালু হতে ব্যর্থ হওয়ার ত্রুটি

লাইসেন্স

এই কাজটি ক্রিয়েটিভ কমন্স অ্যাট্রিবিউশন ২.০ জেনেরিক লাইসেন্সের অধীনে লাইসেন্সকৃত।