• How To Become a DevOps Engineer In Six Months or Less, Part 4: Package
  • By Igor Kantor
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: Raoul1996
  • Proofreader: 7Ethan

How to Become a DevOps Engineer in Six months or Less, Part 4: Packing

“Packages” was photographed by Chuttersnap and published on Unsplash

Quickly review

In Part 1, we talked about the culture of DevOps and the basics needed:

  • How to Become a DevOps Engineer in Six months or Less

In Part 2, we discussed how to lay the groundwork for deploying future code:

  • How to Become a DevOps Engineer in Six months or Less, Part 2: Configuration

In Part 3, we looked at how to organize the deployment code:

  • How to Become a DevOps Engineer in Six months or Less, Part 3: Version Control

In this section, we’ll talk about how to package your code for deployment and subsequent execution.

For reference, here’s our journey:

Note: You can see how each part builds on the previous part and lays the foundation for the subsequent part. This is important and purposeful.

The reason is that whether you talk to a current boss or a future boss, you need to be able to articulate what DevOps is and why it’s important.

You do this by telling a coherent story — a story about how to get code from a developer’s laptop to a profitable production environment (PROD) deployment both well and quickly.

So we’re not learning a bunch of fragmented, trendy DevOps tools, we’re learning a set of skills that are driven by business needs and supported by technical tools.

All right, beep beep enough, let’s get started!

Introduction to Virtualization

Remember physical servers? You have to wait weeks for PO approval, shipping, data center acceptance, shelf placement, networking, OS installation, and patching.

Yes, those were the old ways.

Imagine if the only way to get a place to live was to build a brand new house. Isn’t it a long wait when we need a place to live? That’s interesting. While everyone has a house, it’s not really because it takes so long to build. In this analogy, a physical server is like a house.

Then people got annoyed that it was taking so long to do all this, and some very smart people came up with the idea of virtualization: how to run a bunch of fake “machines” on a single physical machine, with each fake machine masquerading as a real one. Genius!

So, if you really want a house, you can build your own and wait 6 weeks. Or you can live in an apartment building and share resources with other tenants. Maybe not great but good enough. But more importantly, there’s no waiting!

This went on for a while, and VMWare became the dominant company in this area.

Until other smart people decide that packing a bunch of virtual machines into physical machines isn’t good enough: we need to compress more programs into fewer resources in a more compact way.

At this point, houses are too expensive, apartments are too expensive. What if we just need to rent a room temporarily? This is great! I can come and go whenever I want!

Docker was born.

The birth of the Docker

Dokcer is new but the idea behind Docker is old. A system called FreeBSD has a Jails concept that dates back to 2000! It is true that everything new is old.

The idea then, and now, was to isolate individual processes within the same operating system, known as “operating system-level virtualization.”

Note: This is different from “full virtualization,” where virtual machines are running in parallel on the same physical host.

What does this actually mean?

In practice, this means that the rise of Docker neatly mirrors the rise of microservices — an approach to software engineering in which software is broken down into independent components.

And these components need a home. Deploying them separately, deploying standalone Java applications or binary executables is a pain: the way you manage Java applications is different than the way you manage C++ applications, and it’s different than the way you manage Golang applications.

Instead, Docker provides a single management interface that lets software engineers package in a consistent way (!). , deploy and run a variety of applications.

This is a milestone!

OK, let’s talk about more benefits of Docker.

The benefits of the Docker

Process isolation

Docker allows full process isolation for each service. Service A lives in its own container with all of its dependencies, and service B lives in its own container with all of its dependencies, without conflict!

Also, if a container hangs, only that container is affected. The rest will (should) continue to function happily.

The security benefits are also obvious. If the container is compromised, it is very difficult (not impossible!) to leave the container and hack the host system. .

Finally, if the container fails (taking up too much CPU or memory), you can simply “include” the blast radius to the container without affecting the rest of the system.

The deployment of

Think about how to actually build different applications.

If it were a Python application, it would have various Python packages. Some are installed as PIP modules, others are RPM or DEB packages, and others are simple Git Clone installations. Or use virtualenv, which will be all the zip files in the Virtualenv directory.

On the other hand, if it is a Java application, it will be built in Gradle, with all its dependencies pulled and put in place.

You got the point. When deploying these applications into a PROD environment, it can be challenging to have a variety of applications, different languages, and different runtime builds.

How can we keep all our dependencies satisfied?

In addition, if there is conflict, the problem is more serious. What if service A depends on Python library v1, but service B depends on Python library v2? Now there is a conflict because V1 and V2 can no longer coexist on the same machine.

Choose the Docker.

Docker not only allows full process isolation, but also full dependency isolation. It is perfectly feasible and common to run multiple containers side by side on the same operating system, each with its own conflicting libraries and packages.

Runtime management

Again, the way we manage different applications varies from application to application. Java code is logged differently, booted differently, monitored differently than Python, and monitored differently from GoLang, etc.

With Docker, we get a unified management interface that allows us to start, monitor, collect logs, stop and restart many different types of applications.

This is a milestone and significantly reduces the operational overhead of running production systems.

Choose a Lambda

Along with Docker’s greatness, it has drawbacks.

First, Docker is still running on the server. Servers are fragile and must be managed, patched, and otherwise secured.

Second, no one runs Docker exactly as it is. Instead, it is almost always deployed as part of a complex container choreography structure. Examples include Kubernetes, ECS, Docker-swarm or Nomad. These are fairly complex platforms that require dedicated staff to operate (more on these solutions later).

However, if I’m a developer, I just want to write code and have someone else run it for me. Docker, Kubernetes and all this “jazz” is not easy to learn — do I really need it?

In short, it depends!

For those who just want someone else to run their code, AWS Lambda (or a similar solution) is the answer to the question:

AWS Lambda allows you to run code without configuring or managing the server. You only pay for the computing time you consume – nothing when your code is not running.

If you’ve heard of the whole “serverless” movement, that’s it. You no longer need a running server or a container to manage. Just write the code, package it as a ZIP file, upload it to Amazon and let them handle the headaches!

Also, since Lambda is very short, there’s nothing to crack — Lambda is very secure by design.

It’s great, isn’t it?

But (surprise!) Have warned.

First, Lambda will only run for 15 minutes at most (as of November 2018). This means that long-running processes such as Kafka Consumers or number-crunching applications cannot run in Lambda.

Second, Lambda is function-as-a-Service, which means your application must be completely decomposed into microservices and coordinated with other complex PaaS services, such as AWS Step Functions. Not every enterprise is at this level of microservices architecture.

Third, troubleshooting Lambda is difficult. They are run in cloud-native, and all bug fixes happen in the Amazon ecosystem. This is often challenging and unintuitive.

In short, there is no free lunch.

Note: There is now a cloud container solution for “Serverless”. AWS Fargate is such an approach. However, I overlooked this point. Because these tend to be quite expensive and have to be used carefully.

conclusion

Docker and Lambda are two of the most popular modern cloud-native methods for packaging, running, and managing production applications.

They are usually complementary, each suited to slightly different scenarios and applications.

In any case, the modern DevOps engineer must be proficient in both. Therefore, learning Docker and Lambda is a good short – and medium-term goal.

Note: So far in our series, we’ve covered topics that junior to mid-level DevOps engineers should know. In subsequent chapters, we’ll discuss techniques that are more appropriate for mid-to-advanced DevOps engineers. But, as always, there are no shortcuts!

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.