Cloud Computing Köln - Seite 2895 von 7101 - Neues zu Cloud Computing, Internet of Things und Technologien

Your colleagues in IT operations talk about needing a platform that can run a wide variety of apps: new or existing, running on Linux or Windows, long-running or serverless, capable of rapidly scaling up and down according to demand. Anthos is Google Cloud’s answer to these requirements for hybrid and multi-cloud. With Anthos, you not only get to choose how your apps will run but also where the runtimes are located—on-prem, in Google Cloud or in another cloud provider. But that may leave you wondering, “So what does it actually look like to develop on top of Anthos?”Today, we’re excited to launch the Anthos Developer Sandbox, giving you an easy way to learn how to develop on Anthos. With only a few minutes of your time you can get a developer-focused overview of Anthos. Better yet, the Anthos Developer Sandbox is available at no cost, to anyone with a Google account! You don’t need to be a Google Cloud customer, you don’t need to have billing enabled, and you don’t need the help of your IT department to experience Anthos first hand—simply click the button below to get started with the guided flow and then use the Sandbox to create and iterate on your own applications.The Anthos Developer Sandbox includes the following tools, plus a guided flow for learning how to use each of them:Cloud Shell Editor – A development workstation in the cloud. Announced last month and available on ide.cloud.google.com, Cloud Shell Editor makes it easy to deploy cloud-native apps from an in-browser IDE, powered by the Eclipse Theia IDE platform and including all the underlying tools you need.Cloud Code – A set of IDE enhancements that bring you the tools you need for modern cloud-native development like Skaffold and Minikube, and provides an idiomatic and consistent development experience.Cloud Build Local – A tool for running Cloud Build builds locally, without needing an active Google Cloud Platform project.With these three components you have everything you need to iterate on, debug, and test your own applications before deploying to Anthos. Once you have finished experimenting, the Anthos Developer Sandbox cleans up all of the related resources for you. The Anthos Developer Sandbox doesn’t incur any fees as it’s wholly encapsulated in the Cloud Shell free-to-use environment.Cloud Shell Editor (pictured) all within your web-browser.Regardless of which runtime you choose, the Anthos Developer Sandbox guides you to perform common day-to-day development tasks with Anthos, including:Running an application with Cloud Code in a local development environment for Kubernetes that emulates Anthos clustersUsing Cloud Build to run your tests locallyIterating on your application with live updates as you developUsing Buildpacks to simplify your application image creation without needing DockerfilesDeploying your app to the Cloud Run Emulator, which provides a similar experience to Cloud Run for AnthosThe Anthos Developer Sandbox shows you the tools you can use to build an idiomatic developer experience on top Anthos’ container-based runtimes like GKE and Cloud Run. Although we’re focused on developer tasks with this Sandbox, operators may also be interested in Anthos capabilities such as the embedded service mesh and GitOps-style configuration management in the full platform. These capabilities are a good follow on step from the Sandbox. After you’ve completed the Anthos Developer Sandbox guided walkthrough, you can adapt the process to deploy one of your own applications. The following tutorials will help you learn and improve your development experience with Anthos:Deploy to Cloud Run for Anthos on Google Cloud Deploying internal services using Cloud Run for Anthos on Google Cloud Safe rollouts with Anthos Config Management With the Anthos Developer Sandbox, we’re excited to show off the great developer tools that we’ve created for you, and we look forward to helping you have an even more streamlined and productive developer experience. Let us know how you like the Anthos Developer Sandbox by joining the #anthos channel of our Community Slack!
Quelle: Google Cloud Platform

14. November 2020

da Agency

It’s not DNS: Ensuring high availability in a hybrid cloud environment

Our customers have multi-faceted requirements around DNS forwarding, especially if they have multiple VPCs that connect to multiple on-prem locations. As we discussed in an earlier blog post, we recommend that customers utilize a hub-and-spoke model, which helps get around reverse routing challenges due to the usage of the Google DNS proxy range.But in some configurations, this approach can introduce a single point of failure (SPOF) within the hub network, and if there are connectivity issues within your deployment, it could cause an outage in all your VPC networks. In this post, we’ll discuss some redundancy mechanisms you can employ to ensure that Cloud DNS is always available to handle your DNS requests.Figure 1.1 – A non-redundant hub and spoke DNS architectureAdding redundancy to the hub-and-spoke modelIf you need a redundant hub-and-spoke model, consider a model where the DNS-forwarding VPC network spans multiple Google Cloud regions, and where each region has a separate path (via interconnect or other means) to the on-prem network. In the image below, VPC Network H spans us-west1 and us-east1 and each region has a dedicated Interconnect to the customer’s on-prem network. The other VPC networks are then peered with the hub network.Figure 1.2 – A highly available hub-and-spoke architectureThis scenario provides highly available DNS capabilities, allowing the VPC to egress queries out of either interconnect path, and allowing return queries to return via either interconnect path. The outbound request path always leaves Google Cloud via the nearest interconnect location to where the request originated (unless a failure occurred, at which point it uses the other interconnect path). Note, while Cloud DNS will always route the request back to on-prem through the interconnect closest to the region, the responses back from the on-prem network to Google Cloud will depend on your WAN routing. In cases with equal cost routing in place, you may see asymmetric routing behaviors on the return responses, which take a different path than the way they went, and may introduce additional resolution latencies in some cases. Alternative DNS setupsA highly available hub-and-spoke model isn’t an option for all companies, though. Some organizations’ IP address space consists of a mixture of address blocks across many locations. This often happens to companies as a result of a merger or acquisition, which can make it difficult to set up a clean geo-based DNS. Let’s look at a different DNS setup and how customers may have to adapt for failures of the DNS stack.To understand the problem, consider the case of a Google Cloud customer that was managing U.S. East Coast DNS resolvers for East Coast-based VPCs, and U.S. West Coast resolvers for West Coast-based VPCs, in order to reduce latency for DNS queries. The challenge arose when it came time to build out redundancy. Specifically the customer wanted a third set of resolvers to provide backup for both east and west coast resolvers in the event of a failure of either of the resolvers. Unfortunately, a setup like Figure 1.3 could cause issues in a failure scenario.Figure 1.3 – Multiple Hub and Spokes With a Single Set Of Backup DNS ResolversIn this setup, the failure of the West Coast DNS resolvers would result in traffic being forwarded to the backup servers running in the central US, with the source IP addresses for these DNS requests corresponding to Google Cloud’s DNS proxy server address range (35.199.192.0/19). But because there are two VPCs and the WAN sees two different routes to get back to the Google Cloud DNS proxy server address range, it would typically route the return requests back via the closest link advertising the Google Cloud DNS proxy IP range. In this case, that would be the east coast interconnect. And because the east coast interconnect connected to a different VPC than originated the request, the response would be dropped by the Google Cloud DNS proxies (since the Virtual Network ID (VNID) of the return packets would be different from the VNID for the east coast VPC). The problem herein lies with the routing and subnet advertisements, not the DNS layer itself. So the question becomes, how do you support network topologies with multiple VPCs and DNS resolvers while still providing HA DNS resolvers on-premise?One approach is to proxy the DNS request as shown in Figure 1.4 below. By forwarding all DNS requests to a proxy setup within the VPC (or even within a specific subnet, depending on your desired granularity), you end up with VPC-specific IP addresses making it easy for the on-prem infrastructure to correctly send their responses back to the correct VPC. This also simplifies on-prem firewall configurations because you no longer need to open them up for Google’s DNS proxy IP range. Since you can specify multiple IP addresses for DNS forwarding, you can run multiple proxy VMs for additional proxy redundancy and further bolster your availability.Figure 1.4 – Insertion of Proxy VM For HA DNS ConfigurationHighly available DNS: the devil is in the detailsDNS is a critical capability for any enterprise, but setting up highly available DNS architectures can be complex. It’s easy to build a highly redundant DNS stack that can handle many failure scenarios, but overlook the underlying routing until something fails and DNS queries are unable to resolve. When designing a DNS architecture for a hybrid environment, be sure to take a deep look at your underlying infrastructure, and think through how failure scenarios will impact DNS query resolution. To learn more about designing highly available architectures in Google Cloud, check out our patterns for resilient and scalable apps.Related ArticleUnderstanding forwarding, peering, and private zones in Cloud DNSCloud DNS private zones, peering, and logging and auditing enhance security and manageability of your private GCP DNS environment.Read Article
Quelle: Google Cloud Platform

14. November 2020

da Agency

Taking Your App Live with Docker and the Uffizzi App Platform

Tune in December 10th 1pm EST for our Live DockTalk: Simplify Hosting Your App in the Cloud with Uffizzi and DockerWe’re excited to be working with Uffizzi on this joint blog. Docker and Uffizzi have very similar missions that naturally complement one another. Docker helps you bring your ideas to life by reducing the complexity of application development and Uffizzi helps you bring your ideas to life by reducing the complexity of cloud application hosting. This blog is a step-by-step guide to setting up automated builds from your Github repo via Docker Hub and enabling Continuous Deployment to your Uffizzi app hosting environment.

PrerequisitesTo complete this tutorial, you will need the following:

Free Docker Account You can sign-up for a free Docker account and receive free unlimited public repositoriesAn IDE or text editor to use for editing files. I would recommend VSCodeFree Uffizzi App Platform Account Free Github Account

Docker Overview

Docker is an open platform for developing, shipping, and running applications. Docker containers separate your applications from your infrastructure so you can deliver software quickly.

With Docker, you can manage your infrastructure in the same ways you manage your applications. By taking advantage of Docker’s methodologies for shipping, testing, and deploying code quickly, you can significantly reduce the delay between writing code and running it in production.Uffizzi App Platform OverviewUffizzi is a Docker-centric cloud application platform. Uffizzi helps Devs by reducing the complexity of hosting their app in the cloud. Uffizzi automates over a dozen cloud processes and provides push-button app hosting environments that are reliable, scalable, and secure.With Uffizzi you can set up and deploy your application directly from Docker Hub or, as we’ll show in this blog, from Github through Docker Hub’s automated build process. Uffizzi is built upon the open source container orchestrator Kubernetes and allows you to leverage this powerful tool without the complexities of managing cloud infrastructure.

Fork and Clone Example Application

We’ll use an example “Hello World” application for this demonstration, but you can use this workflow with any app that answers HTTP requests.

Login to your GitHub account and “fork” your own copy of this example repository: https://github.com/UffizziCloud/hello-world

To fork the example repository, click the Fork button in the header of the repository:

Wait just a few moments for GitHub to copy everything into your account. When it’s finished, you’ll be taken to your forked copy of the example repository. You can read more about forking GitHub repositories here: https://guides.github.com/activities/forking/

Of course to actually make any changes you’ll need to “clone” your new Git repository onto your workstation. This will be a little different depending on which operating system your workstation is running, but once you have Git installed, `git clone` will usually succeed. The green “Code” button in your repository header provides the URL to clone. You could also use GitHub’s desktop application. You can learn more about Git here: https://guides.github.com/introduction/git-handbook/

Review Code and Dockerfile

Confirm that you have a viable clone by reviewing some of the files within, especially the `Dockerfile`. This file is required to build a Docker image for any application, and it will later be used to automatically build and deploy your new container images. This example `Dockerfile` is extremely simple; your application may require a more sophisticated `Dockerfile`. You can read more about `Dockerfile` anatomy here: https://docs.docker.com/engine/reference/builder/

Create Private Docker Hub Repository

Next, we need somewhere for those built images to reside where Uffizzi can find them. Log in to your Docker Hub account and click on Repositories and then Create Repository.

Be sure to create a Private Repository (not Public) for later Continuous Deployment to Uffizzi.

And now’s a good time to link your GitHub account and add a Build Rule to configure automatic building. Click the GitHub logo and authorize Docker to view your GitHub repository. Click the blue plus sign and create a Build Rule for your `master` branch.

Once you click “Create & Build” you can navigate to your new repository and select the “Builds” tab to see it working (see below screenshot). Once it finishes, your application is ready to deploy on Uffizzi! You can read more about linking GitHub accounts and automatic builds here: https://docs.docker.com/docker-hub/builds/

Setting Up Your Uffizzi App Hosting Environment

Go to https://uffizzi.com and sign up for a free account – there is no credit card required. From the dashboard choose “Get Started Now”. Now choose an environment for your app – “Free” is appropriate for this tutorial.For naming you can use the default name or you can call it “Continuous Deployment Demo” if you’d like.At the “Import Your Application” Step choose Docker Hub and log in to your Docker Hub account.

Once authenticated with Docker Hub select the repo that you’ve created for this demo. This is the repository that later Docker Hub will push your updated image to and kick off the continuous deployment process to your Uffizzi App Hosting environment. After choosing the repo, select your image under “My Images”. You should now be able to indicate the port number that your container listens on – for this tutorial it will be `80`.

We are not connecting to any other services or databases for this demo so environment variables are not required. Now Select “Import”. (Note- if you selected an environment other than “Free” there will be an option to add a database – you can choose “Skip” – a database is not required for this tutorial.)Now you should see your shopping cart with your `hello-world` image. Go ahead and hit the “Deploy” button. Uffizzi will take a few minutes to automate about a dozen cloud processes, from allocating Kubernetes resources to scheduling your container to configuring load-balanced networking to securing your environment. You can “Explore your environment” while you wait.When these steps are complete you will see your container “Running” and you should also see “Continuous Deployment” enabled. Go ahead and click “Open application” to see the application live in your web browser. Later in this tutorial we will come back to this browser tab to see the updates we push from our repository. Later you can configure HTTPS encryption and add a custom domain within the Uffizzi UI, but that’s not necessary for this demo.

Demonstrate Continuous Deployment

Now we can demonstrate Continuous Deployment on Uffizzi. Make a small change to index.html within your workstation’s cloned Git repository, then git push it up to GitHub. Because we connected your GitHub, Docker, and Uffizzi accounts, your changes will immediately deploy to Uffizzi within a new Docker image. This may take a few minutes; check the status in your Docker Hub “Builds” tab.

Confirm Your Update is Live

Now we can see the updates we just made to our application live on Uffizzi! Once you set up your Uffizzi App Hosting environment with Continuous Deployment you don’t have to do anything within Uffizzi to push your code updates. The goal is to make it easy so you can focus on your application!

Confirm Your Update is Live

Conclusion

In this post, we learned about creating private repositories and setting up automated builds with Docker Hub. Next we covered how to deploy our Docker image direct from our Docker Hub private repository into a Uffizzi App Hosting environment. Once our application was live on Uffizzi we ensured “Continuous Deployment” was enabled. This allows Uffizzi to watch our connected Docker Hub repository and automatically deploy new images built there. Next we updated our demo app on our workstation then deployed it to Uffizzi Cloud by executing a `git push` command. This push initiated an automated sequence that took our app from new code pushed to GitHub to a Docker image on Docker Hub to a deployed Uffizzi Hosting Environment. If you have any Docker-related questions, please feel free to reach out on Twitter @pmckee and join us in our community slack.

If you have any Uffizzi-related questions, please feel free to reach out on Twitter to @uffizzi_ and join us in our uffizzi users community slack – Grayson Adkins (grayson.adkins@uffizzi.cloud) or Josh Thurman (josh.thurman@uffizzi.cloud).
The post Taking Your App Live with Docker and the Uffizzi App Platform appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/