ฝึกพูดภาษาอังกฤษด้วยเทคนิค Shadowing จากวิดีโอ: How to design a Deployment Pipeline (GitOps)

เลือกโหมดฝึก

แต่ละโหมดจะเปิดห้องฝึกแบบเต็มจอ

127 ประโยค

หากประโยคสั้นหรือยาวเกินไป กดที่ Edit เพื่อปรับแก้

Hey everyone, in this video we're going to talk about how you can design a deployment pipeline using GetOps principles.

So if you're looking into designing a deployment pipeline or just want to learn a little bit more about GetOps,

this is going to be the video for you.

Now this video takes place after my last video which was how to design a CICD pipeline.

So if you're not sure how to design a CICD pipeline, make sure that you watch my previous video.

I'll let's go ahead and get started with the design of our getops pipeline.

Alright so here you can see that we have a pretty simple CI CD pipeline.

This pipeline takes our application code stored in our application repository, takes it through the source build test and release stage

and basically the output is going to be a container image and that container image is stored in our registry.

So you can see we have our application right here and it's version 1 .0.

So where do we go from here?

This is where we need a continuous deployment pipeline to actually take this application image

and bring it over to our different environments.

So the first thing that we want to do

when designing our deployment pipeline is create a second repository to house our configurations.

So our CI -CD pipeline is going to check out code from our application repo,

but our deployment pipeline is going to use our configurations from our configuration repo.

So this is a traditional GitOps pipeline.

So let's create another repo here, and then we'll call it config repo.

And this config repo is going to contain all the configuration files that we need for deploying our application.

So this could be anything from like Docker Compose files to Kubernetes Manifest.

So let's go ahead and populate this config repo with some manifest files.

So I'm going to put a Kubernetes Manifest file here.

And let's just think about what would be in this manifest.

So in this manifest, we would probably have something like a Kubernetes deployment.

So we'll call it deployment and this deployment probably uses an image

and the image it's going to use is going to be the image from our CI CD pipeline.

So we called it my app and we'll just tag it with v1 .0.

Now let's just move this out of the way and get an environment for us to deploy to.

So we have our server here, and this could be any type of server.

We'll just call it our test slash QA environment.

Now your GitOps pipelines can deploy to your environments in two different models.

The first model is known as the push model.

So we'll call this push.

Now the push model is really simple.

It's as simple as just doing something like a cube control apply.

So we're just going to keep it as that for now.

And then I'm going to discuss the pull model,

which is the more modern approach of actually having an operator installed in your environment that pulls down your configurations.

So let's talk a little bit about how this pipeline gets triggered in the first place.

So your deployment pipeline should be triggered automatically at the end of your CI -CD pipeline.

So let's draw an arrow here from our CI CD pipeline

because it's going to trigger our deployment pipeline as soon as it's done completing.

Now, every time you run your CI CD pipeline, it should be churning out a new version of your application.

So you can see here we have version one of our application.

And the next time we run our pipeline, we're going to get version 1 .1.

Now, if you have a really well -designed pipeline,

what you may want your pipeline to do is to actually go into your configuration repository

and submit a pull request or just push a change to it to actually update the image.

So here I'm going to update the image tag to v1 .1

and all my deployment pipeline really needs to do is rerun kubectl apply

and that's going to deploy it to my test and QA environment.

Now once the code is actually running in your environment, you should have some observability tools plugged in to monitor your application.

So at the very least, you should have something like Prometheus to scrape metrics from your applications.

And then you should have something like Grafana

so your QA teams can actually visualize the changes

and make sure things like the latency hasn't increased and all your key performance indicators are up to snuff.

Now once your deployment has been running in your test and QA environment for some time, what's next is to promote it to your other environments.

So usually you'll have something like.. a staging environment and a production environment.

So staging environments are usually just environments that are similar to production.

It's where you send your deployments first, and you're basically pretending it's production.

You sort of treat it like production, but it's not production.

And then production, of course, is where your live code runs.

This is where the customers are accessing your applications.

So let's draw some arrows to these environments here and the way

that these environments get pushed to is they can automatically get pushed to by your GitOps pipeline

or these can be manually gated by a person.

So sometimes companies aren't comfortable with having everything automatically trigger to their staging and production environments.

Usually they want an engineer to actually run the pipeline manually.

So these ones might be manually or automatically triggered.

Let's now talk about the pull model and then I'll get into canary testing, which is a common thing that's done in production environments.

So with the pull model, I'm just going to take these arrows

and I'm just going to change the direction since they are pulling their configurations and deployments down from our configuration repo.

So instead of CICD server doing a kubectl apply, they would have what's known as an operator installed in them.

So if this is our Kubernetes cluster, then we would have something like Argo CD installed into each of our clusters.

And basically what Argo CD does is it just checks your repository and it checks the state of your clusters.

And if it notices

if the state is different in your clusters than it is in your configuration repo

then it tells you it's out of sync.

Now it can automatically sync your environments for you or it can be manually triggered again.

So you may have your test and QA

and even your staging environments do what's known as an auto synchronization through something like Argo CD

and then you can have your production environment where someone actually needs to click the button to sync the environment.

So Argo CD is really simple to set up actually

and basically you just point it to your get ops repository

and then it just checks your configurations

if anything's out of sync it'll help you sync

it i do have a full length video on how to set up

and get started with argocd so

if you're interested in working with argocd make sure to check

that out i have a link in the description below let's now talk about canary deployments

which is something you should absolutely introduce into any deployment pipeline

So let's talk about how our user actually talks to our application.

So we got some users here, and those users usually talk to our application,

not directly, but they talk through what's known as a load balancer.

So the load balancer is going to load bounce traffic to our application.

So our application is running under a Kubernetes pod.

So we'll just say this is myapp v1 .0 and then we'll say myapp v1 .1.

In a traditional Canary deployment, what would happen is you would have both of the applications deployed.

100

But at the start, it would send 100 % of the traffic to your original application.

101

So we'll say 100 % there and then 0 % here.

102

And then gradually the traffic will be moved over to the new version of your application.

103

So maybe you do it in increments of 10%.

104

So you go 90 % there,

105

10 % there, and then eventually you go 80 % to 20 % and you sort of get the idea.

106

Basically, you're drifting the traffic from the old version to the new version until eventually

107

you have 100 % of the traffic going there.

108

And you can just cut off all the traffic to version one and remove that from your environment.

109

And you just keep doing this for all your new releases.

110

Now, if you're using something like Argo Rollouts in Kubernetes, it would look more like this.

111

This would be actually your rollout object.

112

If you're familiar with Kubernetes, a rollout is basically just a deployment.

113

And a deployment is something that creates your pods, which is basically just your containers.

114

So the rollout object would run a certain number of pods for your version 1 of the application,

115

and then a certain number of pods for version 1 .1.

116

And then as the rollout progresses...

117

It would basically add new pods running the new version of the application

118

and then remove old pods running the old version until eventually all the pods are gone in version one

119

and they're all running in the new version.

120

All right, so I hope this video was helpful on getting to know and understand GitOps and deployment pipelines.

121

If you have any questions, please leave them down below.

122

I know these deployment pipelines can be a little bit confusing at first, especially if you're coming from just designing CICD pipelines,

123

which are pretty much the same no matter which organization you work for.

124

All the stages are sort of the same, but with deployment pipelines, it's really going to be customized to your environment and how your company functions.

125

So make sure to ask some questions below and check out the other videos linked in the description below.

126

I'll have all my Argo related videos that goes over Argo CD as well as one for Argo rollouts.

127

Thanks again for watching and I hope to see you all in the next video.

ดาวน์โหลดแอป

ทุกอย่างที่ต้องใช้เพื่อพูดได้คล่อง

AI ให้คะแนนการออกเสียงให้คะแนนทุกประโยค

ฝึก IPAเชี่ยวชาญทุกเสียง

คำศัพท์สร้างคลังคำของคุณ

เกมคำศัพท์เล่นไปเรียนไป

สแกน QR

Download on theApp Store Get it onGoogle Play

FOR YOU

วิดีโอแนะนำ

90 ประโยค

คำศัพท์และข้อสังเกตด้านการพูดสำหรับบทเรียนนี้

บทเรียนฝึกพูดนี้ใช้วิดีโอ “How to design a Deployment Pipeline” เป็นสื่อ คำที่ถูกพูดซ้ำบ่อยที่สุด: pipeline, environment, deployment, application, version วิดีโอนี้มี 127 ประโยค และ 1713 คำ สำหรับฝึกพูดตาม ช่วงที่มีเสียงพูดยาว 11:01 ผู้พูดพูดด้วยความเร็วเป็นธรรมชาติ ประมาณ 156 คำต่อนาที ใกล้เคียงกับบทสนทนาในชีวิตประจำวัน มีเพียง 81% ของคำที่อยู่ใน 3,000 คำที่ใช้บ่อยที่สุดในภาษาอังกฤษ คำศัพท์จึงค่อนข้างยาก

คำศัพท์สำคัญในวิดีโอนี้

คำที่ควรเรียนรู้ 15 คำจากวิดีโอ พร้อมคำอ่านและความหมาย:

คำศัพท์	คำอ่าน	ความหมาย
trigger คำนาม	/ˈtɹɪɡɚ/	ไก, ไกปืน
pod คำนาม	/ˈpɑd/	ฝัก
server คำนาม	/ˈsɝvɚ/	เซิร์ฟเวอร์
arrow คำนาม	/ˈæɹəʊ/	ลูกศร, ศร
container คำนาม	/kənˈteɪ.nəɹ/	บรรจุภัณฑ์, หีบห่อ
gate คำนาม	/ˈɡeɪ̯t/	ประตู
output คำนาม	/ˈaʊtpʊt/	เอาท์พุต
introduce คำกริยา	/ˌɪntɹəˈdus/	แนะนำ
monitor คำนาม	/ˈmɑ.nɪ.tɚ/	จอภาพ, หน้าจอ
principle คำนาม	/ˈpɹɪn.sɪ.pəl/	หลัก, คติ
submit คำกริยา	/səbˈmɪt/	ยอมแพ้, ยอม
plug คำนาม	/plʌɡ/	ปลั๊ก, เต้าเสียบ
bounce คำกริยา	/baʊns/	เด้ง
automobile คำนาม	/ˈɔː.tə.məˌbil/	รถยนต์, รถ
metric คำคุณศัพท์	/ˈmɛt.ɹɪk/	เมตริก

ไวยากรณ์ในวิดีโอนี้

โครงสร้างที่ผู้พูดใช้บ่อยที่สุด พร้อมคำพูดจริงจากวิดีโอ:

โครงสร้าง	ในวิดีโอ
Passive voice be + กริยาช่อง 3 — เน้นสิ่งที่เกิดขึ้น ไม่ใช่ผู้กระทำ	is stored · is known · should be triggered
Relative clauses who / which + อนุประโยค — ข้อมูลเพิ่มเติมเกี่ยวกับคนหรือสิ่งของ	video which was · testing, which is · pods, which is

การออกเสียงที่ควรระวัง

ผู้พูดใช้รูปย่อและรูปลดเสียง 32 ครั้ง เช่น we'll, you're, I'm ให้พูดแบบสั้นตามที่ได้ยิน

เสียง “sh” และ “zh”: configuration /kənˌfɪɡ.əˈɹeɪ̯.ʃən/, visualize /ˈvɪʒuəˌlaɪz/
คำยาว — ลงเสียงหนักให้ถูกพยางค์: configuration /kənˌfɪɡ.əˈɹeɪ̯.ʃən/, manually /ˈmænj(u)əliː/, operator /ˈɑpəˌɹeɪtɚ/, continuous /kənˈtɪn.juː.əs/, automobile /ˈɔː.tə.məˌbil/

เสียงที่คนไทยมักออกเสียงยาก:

เสียงท้ายคำ — ออกเสียงให้ครบ ไม่เปลี่ยนเป็นตัวสะกดแบบไทย: introduce /ˌɪntɹəˈdus/, principle /ˈpɹɪn.sɪ.pəl/, continuous /kənˈtɪn.juː.əs/, bounce /baʊns/, automobile /ˈɔː.tə.məˌbil/
/v/ — ไม่ใช่ /w/ ให้ฟันบนแตะริมฝีปากล่าง: server /ˈsɝvɚ/, visualize /ˈvɪʒuəˌlaɪz/
/z/ — เสียงก้อง ไม่ใช่ /s/: confuse /kənˈfjuːz/, repository /ɹɪˈpɒz.ɪ.t(ə.)ɹɪ/, customize /ˈkʌs.tə.maɪ̯z/, visualize /ˈvɪʒuəˌlaɪz/

วิธีฝึกกับวิดีโอนี้

ฟังวิดีโอให้จบหนึ่งรอบโดยยังไม่ต้องพูด แล้วจดคำที่ยังไม่รู้จัก
เริ่มที่ความเร็ว 0.75× พูดตามทีละประโยค แล้วกลับไปใช้ความเร็วปกติเมื่อเริ่มคล่อง
อัดเสียงตัวเองแล้วเทียบกับต้นฉบับ โดยสังเกตคำอย่าง trigger, pod, server เป็นพิเศษ

เทคนิค Shadowing คืออะไร?

Shadowing เป็นเทคนิคการเรียนรู้ภาษาที่ได้รับการรับรองทางวิทยาศาสตร์ พัฒนาขึ้นสำหรับการฝึกนักแปลมืออาชีพ วิธีการนี้เรียบง่ายแต่ทรงพลัง: คุณฟังเสียงภาษาอังกฤษจากเจ้าของภาษาและพูดตามทันที — เหมือนเงาที่ตามผู้พูดด้วยช่วงเวลาห่าง 1-2 วินาที การวิจัยแสดงว่าเทคนิคนี้ปรับปรุงความแม่นยำในการออกเสียง ทำนองเสียง จังหวะ การเชื่อมเสียง การฟังเข้าใจ และความคล่องแคล่วในการพูดได้อย่างมีนัยสำคัญ

เทคนิค shadowing: อ่านคู่มือฉบับเต็มทีละขั้นตอน →

ฝึกพูดภาษาอังกฤษด้วยเทคนิค Shadowing จากวิดีโอ: How to design a Deployment Pipeline (GitOps)

เลือกโหมดฝึก

ดาวน์โหลดแอป

If you’re an aspiring product designer, watch this (roadmap included)

Did Anthropic Kill Git?

What is Docker? Docker container concept explained || Docker Tutorial 1

Design a File Upload Service Like a Senior Engineer

STOP Running Code On Your Computer

Database Sharding! Designing Data-Intensive Applications chapter 6

Prompt Engineering - Guidelines

SDLC Vs STLC: Software Development Life Cycle and Software Testing Life Cycle

Best NextJS Folder Structures | Beginner - Intermediate - Advanced

How I Learned Procedural Generation

Inside a Biotech Company: Roles, Teams & Where You Could Fit In | EP 14

GitHub Copilot now controls your command line...