cloud computing News, Entwicklungen, Updates, HowTos - Seite 2315 von 7138

Guest author Ben Hall is the lead technical developer for C# .NET at gov.uk (a United Kingdom public sector information website) and a .NET Foundation foundation member. He worked for nine years as a school teacher, covering programming and computer science. Ben enjoys making complex topics accessible and practical for busy developers.

Deciding Between Docker Desktop and a DIY Solution

At the heart of the Docker experience is Docker Engine. Docker Desktop’s ready-to-use solution for building containerized applications includes Docker Engine and all the other tooling and setup you need to start developing right away.

Developers can create a “DIY” Docker implementation around Docker Engine manually. Some organizations may prefer the flexibility and control of doing it themselves. But opting for a DIY Docker Engine solution requires much more engineering, development, and setup. Docker and its Windows companion, WSL, are relatively complex, so the DIY approach isn’t for everyone.

In this article, we’ll help you decide which approach is right for you and your organization. To illustrate, we’ll draw comparisons between what Docker Desktop offers and a DIY Docker setup on Windows.

Setting Up Docker on Windows

This article on failingfast.io describes the main steps for a manual installation on Windows, which involves creating a WSL 2 distro, setting up a Docker repository, and installing the Docker Engine on the WSL 2 distro additional setup. This process is a bit fragile, so prepare for troubleshooting before you’re up and running. And it’s only a guide to getting started. Most use cases will need further setup, including:

Configuring Docker to start on bootLoggingAccepting connections to Docker daemon from remote hostsConfiguring remote accessFixing IP forwarding problems

Setting up Docker Desktop is a very different experience. You simply download and run the latest Docker Desktop installer — it automatically completes all the work. We’re up and running in a few minutes, ready to deploy containers.

Cutting Edge and Stable

Docker Desktop and the DIY implementation that we linked to share a common foundation on Windows Subsystem for Linux (WSL) 2 that enables developers to run a Linux environment directly on Windows.

WSL 2 significantly improved memory use, code execution, and compatibility. It achieved this through an architectural shift to a full Linux kernel, which supports Linux containers running natively, without emulation.

Working closely with Microsoft and Windows Insider, Docker was quick to adopt this beneficial emerging technology as the primary backend for Docker Desktop. Docker then released a technical preview far in advance of WSL 2 reaching general availability in Windows. Every effort was made also, to maintain feature parity with the previous version that used Hyper-V.

We can add Docker Desktop to our developer tooling, confident that it will continue to support that latest technology while avoiding breaking changes to the experience we are accustomed to.

Software Updates

Docker Desktop manages everything, from setup through to future kernel patches. And because it’s a complete bundle, the automatic software updates will keep all the tools installed on it up-to-date and secure, including the Docker Engine itself. That’s one less machine image to manage in-house!

With a DIY Docker setup, it’s up to you to keep up with all security patches and other updates. A DIY solution will also provide you with plenty of ongoing problems that need solving. So, be sure to multiply those developer hours across a large organization when you are calculating the ROI for Docker Desktop.

Networking

Docker Desktop will automatically propagate configured HTTP/HTTPS proxy settings to Docker to use when pulling containers.

It will also function properly when attached to a VPN. It achieves this by intercepting traffic from containers and injecting it into Windows as if it originated from the Docker application itself.

Pause and Resume

This feature was requested by a user on the public roadmap for Docker Desktop. It’s not the biggest feature ever, but it’s another great reminder that Docker Desktop is under active development. It’s continually being improved in response to user feedback, implemented with monthly releases.

Users can now pause a Docker Desktop session to reduce CPU usage and conserve battery life. When paused, the current state of all your containers is saved in memory and all processes are frozen.

Volume Management

Volumes are the standard approach to persisting any data that Docker containers work with, including files shared between containers. Unlike bind mounts, which work directly with host machine files, volumes are managed by Docker, offering several advantages.

You’ll face two big challenges when working with Docker volumes manually in the Docker CLI:

It can be difficult to identify which container each volume belongs to, so clearing up old volumes can be a slow process.Transferring content in and out of volumes is more convoluted than it really needs to be.

Docker Desktop provides a solution for this by providing a view in the Dashboard to explore volumes. In this view, you can:

Easily identify which volumes are being used See which containers are using a volumeCreate and delete volumesExplore the files and folders in a volume, including file sizesDownload files from volumesSearch and sort by name, date, and size

Kubernetes Integration

Although there are too many features to explore in a single article, we should take a look at the Kubernetes integration in Docker Desktop.

Kubernetes has become a standard for container orchestration, with 83 percent of respondents to the 2020 CNCF Survey reporting that they use it in production.

Granted, we don’t need Kubernetes to get Docker’s benefits in local development, like the isolation from the host system. Plus, we can even use Docker Compose 2.0 to run multiple containers with some nifty networking features. But if you’re working on a project that will deploy to Kubernetes in production, using a similar environment locally is a wise choice.

In the past, a local Kubernetes instance was something else to set up, and the costs in developer time didn’t offer enough benefit to some. This is likely still the case for a DIY Docker solution.

Docker Desktop, in contrast, comes with a standalone Kubernetes server and client for local testing. It’s an uncomplicated, no-configuration, single-node cluster. You can switch to it through the UI, as the image below shows, or in the usual way with kubectl config use-context.

Native Apple Silicon Support

In 2021, a version of Docker Desktop for Mac that could fully leverage the latest M1 chip reached general availability. There are already over 145,000 ARM-based images on Docker Hub. This Apple Silicon version supports multi-platform images, which means you can build and run images for x86 and ARM architectures without complex cross-compilation environments.

This was very well-received because the emulation offered by Rosetta 2, which offers acceptable functionality for many common applications, isn’t sufficient to run containers.

Costs and Scalability

The DIY alternative requires a great deal of engineering time to build and configure, with an ongoing maintenance commitment for updating, patching, and troubleshooting the container environment. Each developer in an organization will carry out most of this work individually every time they work in a fresh environment.

This approach doesn’t scale well! It means developers won’t be spending time on activities directly benefiting the business, like new features. None of us enjoy a sprint review where we have to explain that we didn’t deliver a feature because of problems with or work setting up development environments.

Containerization should help facilitate product delivery. What Docker Desktop sets out to achieve is not new. We have always invested in programming IDEs and other tooling that bundle functionality in a single, user-friendly package to improve productivity.

To help you determine whether Docker Desktop is right for your organization from a cost perspective, Jeremy Castile has some guidance to help you assess the ROI.

Working with Multiple Environments

Developers widely accept that build artifacts must be immutable — the same application, built, must move through QA to production. The next level, if you’d like, is packaging an application and its dependencies together. This helps to further maintain consistency between development, testing, and production environments.

We risk not realizing this benefit if the process is too complicated. Organizations have introduced many great tools and processes to teams, only for these tools to gather dust because the entry bar for the required skills is too high.

This situation is more prominent in QA teams. Many testers are technical, but more typically, they have a particular set of skills geared towards testing. Since QA is one group set to benefit a great deal from consistent testing environments, consider what they are most likely to use.

Introducing Dev Environments

To improve the experience further for these scenarios, Docker Desktop has added a new collaborative development feature, currently in preview, called Dev Environments.

Switching git branches or environments usually requires lots of manual changes to configuration, dependencies, and other environment setup before it’s possible to run the code.

The new feature makes it easy to keep the environment details themselves in source control with the code. With a click of a button, a developer can share their work-in-progress and its dependencies via Docker Hub. This means developers can easily switch to fully functioning instances of each other’s work to, for example, complete a pull request without having to change from their local branch and make all those environment changes.

Get started in Development Environments with the preview documentation.

Conclusion

Bret Fisher, an author who writes about Docker, summed up the need for Docker Desktop: “It’s really a testament to Docker Desktop that there isn’t a comparable tool for local Linux containers on macOS/Windows that solves 80% of what people typically need out of a container runtime locally.”

We’ve explored what Docker Desktop offers and along the way. We’ve also touched on the subjects of cost and ROI, setup and maintenance, scalability, and onboarding. Although some will prefer DIY Docker’s flexibility and control, Docker Desktop requires less setup effort and maintenance, offering a gentler learning curve for everyone from development to QA.

Perhaps the greatest challenge of a DIY solution is from a business value perspective. Developers love discovering how to do these things. So, a developer won’t necessarily track how many hours they spent over a week engaged in maintaining a DIY solution — the business will have no visibility into any productivity loss.If you’re still using a DIY solution for local development with Docker on Windows or macOS, learn more about Docker Desktop and download it to get started.
The post Guest Blog: Deciding Between Docker Desktop and a DIY Solution appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

8. Januar 2022

da Agency

Are you a multicloud engineer yet? The case for building skills on more than one cloud

Over the past few months, I made the choice to move from the AWS ecosystem to Google Cloud — both great clouds! — and I think it’s made me a stronger, more well-rounded technologist.But I’m just one data point in a big trend. Multicloud is an inevitability in medium-to-large organizations at this point, as I and others have been saying for awhile now. As IT footprints get more complex, you should expect to see a broader range of cloud provider requirements showing up where you work and interview. Ready or not, multicloud is happening.In fact, Hashicorp’s recent State of Cloud Strategy Survey found 76% of employers are already using multiple clouds in some fashion, with more than 50% flagging lack of skills among their employees as a top challenge to survival in the cloud.That spells opportunity for you as an engineer. But with limited time and bandwidth, where do you place your bets to ensure that you’re staying competitive in this ever-cloudier world?You could pick one cloud to get good at and stick with it; that’s a perfectly valid career bet. (And if you do bet your career on one cloud, you should totally pick Google Cloud! I have reasons!) But in this post I’m arguing that expanding your scope of professional fluency to at least two of the three major US cloud providers (Google Cloud, AWS, Microsoft Azure) opens up some unique, future-optimized career options.What do I mean by ‘multicloud fluency’? For the sake of this discussion, I’m defining “multicloud fluency” as a level of familiarity with each cloud that would enable you to, say, pass the flagship professional-level certification offered by that cloud provider–for example, Google Cloud’s Professional Cloud Architect certification or AWS’s Certified Solutions Architect Professional. Notably, I am not saying that multicloud fluency implies experience maintaining production workloads on more than one cloud, and I’ll clarify why in a minute.How does multicloud fluency make you a better cloud engineer?I asked the cloud community on Twitter to give me some examples of how knowledge of multiple clouds has helped their careers, and dozens of engineers responded with a great discussion.Turns out that even if you never incorporate services from multiple clouds in the same project — and many people don’t! — there’s still value in understanding how the other cloud lives.Learning the lingua franca of cloudI like this framing of the different cloud providers as “Romance languages” — as with human languages in the same family tree, clouds share many of the same conceptual building blocks. Adults learn primarily by analogy to things we’ve already encountered. Just as learning one programming language makes it easier to learn more, learning one cloud reduces your ramp-up time on others.More than just helping you absorb new information faster, understanding the strengths and tradeoffs of different cloud providers can help you make the best choice of services and architectures for new projects. I actually remember struggling with this at times when I worked for a consulting shop that focused exclusively on AWS. A client would ask “What if we did this on Azure?” and I really didn’t have the context to be sure. But if you have a solid foundational understanding of the landscape across the major providers, you can feel confident — and inspire confidence! — in your technical choices.Becoming a unicornTo be clear, this level of awareness isn’t common among engineering talent. That’s why people with multicloud chops are often considered “unicorns” in the hiring market. Want to stand out in 2022? Show that you’re conversant in more than just one cloud. At the very least, it expands the market for your skills to include companies that focus on each of the clouds you know.Taking that idea to its extreme, some of the biggest advocates for the value of a multicloud resumé are consultants, which makes sense given that they often work on different clouds depending on the client project of the week. Lynn Langit, an independent consultant and one of the cloud technologists I most respect, estimates that she spends about 40% of her consulting time on Google Cloud, 40% on AWS, and 20% on Azure. Fluency across providers lets her select the engagements that are most interesting to her and allows her to recommend the technology that provides the greatest value.But don’t get me wrong: multicloud skills can also be great for your career progression if you work on an in-house engineering team. As companies’ cloud posture becomes more complex, they need technical leaders and decision-makers who comprehend their full cloud footprint. Want to become a principal engineer or engineering manager at a mid-to-large-sized enterprise or growing startup? Those roles require an organization-wide understanding of your technology landscape, and that’s probably going to include services from more than one cloud. How to multicloud-ify your careerWe’ve established that some familiarity with multiple clouds expands your career options. But learning one cloud can seem daunting enough, especially if it’s not part of your current day job. How do you chart a multicloud career path that doesn’t end with you spreading yourself too thin to be effective at anything?Get good at the core conceptsYes, all the clouds are different. But they share many of the same basic approaches to IAM, virtual networking, high availability, and more. These are portable fundamentals that you can move between clouds as needed. If you’re new to cloud, an associate-level solutions architect certification will help you cover the basics. Make sure to do hands-on labs to help make the concepts real, though — we learn much more by doing than by reading.Go deep on your primary cloudFundamentals aside, it’s really important that you have a native level of fluency in one cloud provider. You may have the opportunity to pick up multicloud skills on the job, but to get a cloud engineering role you’re almost certainly going to need to show significant expertise on a specific cloud.Note: If you’re brand new to cloud and not sure which provider to start with, my biased (but informed) recommendation is to give Google Cloud a try. It has a free tier that won’t bill you until you give permission, and the nifty project structure makes it really easy to spin up and tear down different test environments.It’s worth noting that engineering teams specialize, too; everybody has loose ends, but they’ll often try to standardize on one cloud provider as much as they can. If you work on such a team, take advantage of the opportunity to get as much hands-on experience with their preferred cloud as possible.Go broad on your secondary cloudYou may have heard of the concept of T-shaped skills. A well-rounded developer is broadly familiar with a range of relevant technologies (the horizontal part of the “T”), and an expert in a deep, specific niche. You can think of your skills on your primary cloud provider as the deep part of your “T”. (Actually, let’s be real — even a single cloud has too many services for any one person to hold in their heads at an expert level. Your niche is likely to be a subset of your primary cloud’s services: say, security or data.)We could put this a different way: build on your primary cloud, get certified on your secondary. This gives you hirable expertise on your “native” cloud and situational awareness of the rest of the market. As opportunities come up to build on that secondary cloud, you’ll be ready.I should add that several people have emphasized to me that they sense diminishing returns when keeping up with more than one secondary cloud. At some point the cognitive switching gets overwhelming and the additional learning doesn’t add much value. Perhaps the sweet spot looks like this: 1< 2 > 3.Bet on cloud-native services and multicloud toolingThe whole point of building on the cloud is to take advantage of what the cloud does best — and usually that means leveraging powerful, native managed services like Spanner and Vertex AI. On the other hand, the cloud ecosystem has now matured to the point where fantastic, open-source multicloud management tooling for wrangling those provider-specific services is readily available. (Doing containers on cloud? Probably using Kubernetes! Looking for a DevOps role? The team is probably looking for Terraform expertise no matter what cloud they major on.) By investing learning time in some of these cross-cloud tools, you open even more doors to build interesting things with the team of your choice.Multicloud and youWhen I moved into the Google Cloud world after years of being an AWS Hero, I made sure to follow a new set of Google Cloud voices like Stephanie Wong and Richard Seroter. But I didn’t ghost my AWS-using friends, either! I’m a better technologist (and a better community member) when I keep up with both ecosystems. “But I can hardly keep up with the firehose of features and updates coming from Cloud A. How will I be able to add in Cloud B?” Accept that you can’t know everything. Nobody does. Use your broad knowledge of cloud fundamentals as an index, read the docs frequently for services that you use a lot, and keep your awareness of your secondary cloud fresh:Follow a few trusted voices who can help you filter the signal from the noiseAttend a virtual event once a quarter or so; it’s never been easier to access live learningBuild a weekend side project that puts your skills into practiceUltimately, you (not your team or their technology choices!) are responsible for the trajectory of your career. If this post has raised career questions that I can help answer, please feel free to hit me up on Twitter. Let’s continue the conversation.Related ArticleFive do’s and don’ts of multicloud, according to the expertsWe talked with experts about why to do multicloud, and how to do it right. Here is what we learned.Read Article
Quelle: Google Cloud Platform