Kategorie: Kubernetes

Top 12 Questions from the Docker Enterprise 3.0 Webinar Series

Earlier in August, we hosted a series of virtual events to introduce Docker Enterprise 3.0. Thousands of you registered and joined us, and many of you asked great questions. This blog contains the top questions and answers from the event series.

Docker Enterprise in the Cloud, On-Prem, with Kubernetes
Q: Can Docker Enterprise be used on AWS and other cloud providers?
A: Yes! Docker Enterprise, including the Docker Universal Control Plane (UCP) and Docker Trusted Registry (DTR), can be deployed to any of the leading cloud environments, including AWS, Azure and GCP. With Docker Enterprise 3.0, we also launched the Docker Cluster CLI plugin for use with Docker Certified Infrastructure. The plugin (now supporting AWS and Azure) allows for simple installation and upgrading of Docker Enterprise on selected cloud providers.
Q: Is Docker Cluster only available in the public cloud, or is it possible to add local machines or VMs?
A: Additional support for VMware vSphere environments is coming shortly. If you have other platforms that need to be supported, please engage with your account team to provide that feedback!
Q: Does Docker Kubernetes Service (DKS) work with both on-premises and other Kubernetes environments such as EKS, AKS, GKE?
A: Docker Kubernetes Service is an integrated and certified Kubernetes distribution that is included in the Docker Enterprise platform – both in Docker Desktop Enterprise and in our Universal Control Plane (UCP). As a conformant Kubernetes distribution, there is an inherent compatibility between Docker Kubernetes Service and other cloud-based Kubernetes environments. However, if you are using EKS/AKS/GKE, you will not need to install another Kubernetes distribution for your runtime environment and that means you will not need UCP. You will still benefit from other elements of the Docker platform including Docker Desktop Enterprise for local developer environments and Docker Hub and Docker Trusted Registry for collaborating with trusted content. 
Q: My organization is new to containers and Kubernetes – what’s the recommended path to get started?
A: Most of our customers are new to these technologies. Docker Enterprise Solutions offer an easy on-ramp for customers to deploy and operationalize Docker Enterprise (including Docker Kubernetes Service) within their environments. Solutions include Docker Enterprise platform subscriptions and professional services that leverage a prescriptive methodology developed over time working with hundreds of enterprise customers. You can learn more at docker.com/solutions/docker-enterprise-solutions.
Docker Enterprise 3.0 Security
Q: Is there a way to determine that an image in Docker Hub is validated and has the appropriate security settings?
A: Official and Verified Publisher images provide a first level screen in terms of validating that they came from a trusted source – either with Docker’s direct oversight or from validated 3rd party vendors. The Certified Images in Docker Hub must be run through an additional security test. To provide an even higher level assurance, we recommend scanning the images for known vulnerabilities once they are added to your own private registry.
Q: What if a vulnerability is discovered after you have deployed it to production? Will you be alerted?
A: Yes! Docker Enterprise tracks the layers that have been scanned. If a new vulnerability is detected, you will be alerted on previously scanned images and, using UCP, have the ability to track where those images are deployed. 
We track vulnerabilities closely – each of the Official images can be traced back to Github. The vulnerability scanning capabilities will compare the layers in the image against the CVE database. If there is an older release version of software contained in the image, vulnerability scanning (binary level scanning) will pick that up and flag it. Then you can re-build that image with the latest patch
Docker Desktop, Docker App and CNAB
Q: How Docker Desktop Enterprise different than the community version?
The key differences are in two areas: developer productivity and IT manageability. To improve productivity, Docker Desktop Enterprise includes an application designer interface that makes it easy to build container-based applications using pre-defined templates. When it comes to improving manageability, Docker Desktop Enterprise can be deployed via IT’s choice of endpoint management tools, with optional lockable settings. You can see a full list of enhancements here.
Q: I want our developers to work with Docker on Windows desktops, but the production environments are Linux. Can they develop for Linux in Docker Desktop for Windows?
A: Yes! Docker Desktop for Windows already exists today for native .NET and Linux based development. We also recently introduced the Tech Preview to support WSL2 – an improved Linux experience within Windows! You can learn more about WSL2 here.
Q: Is CNAB a viable solution for deploying edge architecture applications?
A: Yes. The CNAB specification is designed to support multiple configuration formats, making it future-proof and inclusive of things like Helm charts and Object YAML files. That allows you to support both existing tech stacks and future tech stacks.
Q: What application frameworks does Docker App support?
A: There is no restriction on application frameworks for Docker App. Today, Docker App supports the packaging of multiple Docker Compose files into a single bundle. These Compose files can be mapped to monolithic or n-tier applications or microservices – there is no dependency on the application architecture. As Docker App expands to support Helm charts and Kubernetes YAML, this will further embrace other configuration formats.
Q: Is there an easy way in Docker App to convert any custom development app to a container ready app?
A: We have some tooling to assist on this. Using Assemble and Templates adds your code to a “scaffold” for containers. Someone does have to create the template – but it is possible to reuse other templates that others have created.
Q: Does Docker App depend on the underlying infrastructure in terms of virtual machines, bare metal, etc.?
A: The underlying infrastructure generally doesn’t matter. Docker Enterprise runs on VMs or bare metal and the parameterized fields within the Docker App can be used to adjust settings (like the port setting) so that you can be adjusted at deployment. 
Build, Share and Run Anywhere
The questions attendees asked made it clear that developers and ops teams alike value choice and flexibility. They want to be able to build, share and run applications anywhere, and have the peace of mind that applications are secure.
You can learn more by catching the on-demand 5 part webinar series.
Get the On-Demand Series

The Top 12 questions from our Docker Enterprise 3.0 webinar seriesClick To Tweet

To learn more about Docker Enterprise 3.0:

Check out what’s new in 3.0
Learn about Docker Desktop Enterprise

The post Top 12 Questions from the Docker Enterprise 3.0 Webinar Series appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

5 Things That Happen When You Get Locked In to an Application Platform

The Consequences of Application Platform Lock-in 
If you’ve worked in IT for a few years, you’ve seen it happen. You select an application framework, operating system, database platform, or other infrastructure because it meets the checklist, the price is right, or sometimes because of internal politics. You quickly discover that it doesn’t play well with other solutions or across platforms — except of course it’s “easy and seamless” when used with offerings from the same vendor.

But try telling your developers that they can’t use their favorite framework, development toolset, or have to use a specific operating system for everything they do. If developers feel like they don’t have flexibility, they quickly adopt their own tools, creating a second wave of shadow IT.
And it doesn’t just affect developers. IT operations and security get bogged down in managing multiple systems and software sprawl. The business suffers because efficiency and innovation lag when teams get caught up in fighting fires.
Below are 5 things that can go wrong when you get locked in to an infrastructure platform:
#1 Other Platforms Become Inaccessible
Will the platform you pick work with any combination of public and private clouds? Will you get cornered into using a specific operating system for anything tied to their platform? When an infrastructure vendor pushes you to use their other platforms because they’re “well-integrated,” think carefully about whether you’re willing to limit your choices as this will likely cost more and result in unhappy developers.
#2 Your Best Developers Find Other Opportunities
Developers want to work with the best frameworks and tools for their task at hand. Node.js and .NET Core may be popular with developers, but there are a wide range of tools out there. The  2019 Stack Overflow Developer survey results, make it clear that  developers have diverse preferences and work best when they have the most choice and flexibility.
#3 Application Development Will Slow Down
If developers are forced into a particular development framework, innovation and creativity can be hindered. Good developers rarely have trouble finding work, so your best talent may leave. Even if most of your developers stick around, they’ll spend more time testing applications across platforms. What works on one machine won’t necessarily work on another if developers are busy finding work-arounds to use the tools they prefer.
#4 Operations Teams Will Spend More Time Fighting Fires
Keeping the lights on already consumes 70 to 80 percent of IT budgets. Using application platforms and tools from a single vendor may seem like it will save time, but the reality can be quite different. Other solutions come into the picture (usually whether you want them to or not!), creating silos of infrastructure that IT ops teams need to look after.
#5 The Business May Not Be Able to Pick the Best Technology
If you’re stuck primarily with one platform and framework but a new, promising tool isn’t compatible, you can either adopt another platform or pick a second-rate tooling. Platform lock-in means the business can end up forced to make technology choices that ultimately don’t serve the best interests of the company.
Platform Lock-in is Bad for Your Business
At Docker, we believe in simplicity and choice. We simplified containers and offer the broadest choice for developers and operators. You should be able to build, share and run applications across any combination of clouds, operating systems, languages and frameworks. That’s why Docker Enterprise works with every cloud provider, runs on all major operating systems, and supports Kubernetes for orchestration across that hybrid architecture. It’s no accident that containerd, the runtime engine developed by Docker, is the industry standard.
And developers love the flexibility Docker gives them. They even ranked Docker as the #1 “Most Loved Platform”, #2 “Most Wanted Platform” and #3 “Platform In Use” in the Stack Overflow survey. 
Start a Free Trial

5 Things That Happen When You Get Locked In to an App PlatformClick To Tweet

To learn more about how Docker gives you simplicity and choice:

Try a free, hosted trial or catch our Docker Enterprise 3.0 Launch Webinar Series
Learn about Docker for Developers
Learn more about the Docker Kubernetes Service

The post 5 Things That Happen When You Get Locked In to an Application Platform appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Don’t Pick an Ops Platform Your Devs Won’t Use

In all of the excitement and buzz around Kubernetes, one important factor in the conversation that seems to be glossed over is how and where containerized applications are built. Going back to Docker’s roots, it was developers who were the first ones to adopt Docker containers. It solved their own local development issues and made it easier and faster to get applications out the door.
Fast forward 5 years, and developers are more important than ever. They build modern apps and modernize existing apps that are the backbone of organizations. If you’re in IT operations and selecting application platforms, one of the  biggest mistakes you can make is making this decision in isolation, without development buy-in. 
Avoiding Shadow IT, Round 2
In the early days of public cloud, developers started going around IT to get fast access to computing resources, creating the first round of “Shadow IT”.  Today, most large enterprises have embraced cloud applications and infrastructure, and work collaboratively across application development and operations teams to serve their needs.
But there’s a risk we’ll invite the same thing to happen again by making a container platform decision that doesn’t involve your developers. Here are 3 reasons to include developers in your platform decisions.
1. Intuitive Tooling = Developer Productivity
Developers are resourceful, but they want tools and solutions that are simple and “just work”; it makes their job easier. They want familiar tools, where they can invoke commands they know well. This translates into greater productivity and more energy being put towards innovation. Some enterprises even measure developer onboarding time as a performance indicator. 
Millions of developers use Docker Desktop already because it works with standard Docker and Kubernetes CLIs, without new commands to learn or workflows to master. They can integrate directly with their IDE and CI tools without having to relearn how to build apps. 
With Docker Desktop Enterprise, developers can create a local, certified Kubernetes environment with a single click. We make it even simpler to build containerized applications for those without prior Docker knowledge with the new Application Designer GUI and customizable application templates.
Ensuring your application platform works consistently with your developers’ tools will ensure tighter integration between the groups. 
2. Platform for Today & Tomorrow
For many enterprises, the technology stacks of yesterday are not the ones in use today; and the technology stacks of tomorrow will likely be different than what is being used today. In the search to improve developer productivity, development teams also explore new application stacks that make their job easier – new languages, new frameworks and architectures, new operating systems. New platforms enter the mix this way. 
Put another way, your development teams want to pick and choose the right tools for the job and not be forced into using a single operating system or language. If you can give them choice and flexibility to use the platforms that best suit their need, you can avoid the second wave of “shadow IT.”  This will also help operations teams who wish to have flexibility in where applications are deployed – whether that is on-premises, virtual or bare metal, or in one or more public clouds.
The Docker Platform provides a fully agnostic approach to containerization – supporting any language or framework and any infrastructure. With the new Docker Application packaging framework, we also look to extend beyond containers and support applications that may include cloud-based services and serverless functions down the road. 
3. Intrinsic Security
Everyone knows security is important, but it’s often seen as a hindrance to developer productivity. Operations teams can help developers build secure applications by providing guardrails and governance models that are built into the development lifecycle.
One of the best ways to do this is by providing pre-approved application templates to your developers. These are the scaffolding of modern applications that have security intrinsically built-in. They leverage approved technology stacks that are pre-screened for known vulnerabilities, ensuring that all patches are in place. Docker Desktop Enterprise and Docker Trusted Registry combine to provide these capabilities so that your developers can ship production-ready code faster. 
The Proof is in the Results
Application platform investments can often stall or just don’t see much adoption. Working closely with your application architects and development teams ensures that your investments in Kubernetes and a container platform will not go to waste. Our experience with over 800 enterprise organizations who rely on Docker Enterprise demonstrates how organizations that can bring Dev and Ops together improve collaboration and drive more value than those that do not.

Don’t pick an ops platform your devs won’t use. Here are 3 reasons to include #developers in your platform decisions:Click To Tweet

Start a Free Trial
To learn more about building, sharing, and running modern applications: 

Try a free, hosted trial or catch our Docker Enterprise 3.0 Launch Webinar Series
If you’re attending VMworld in San Francisco, stop by booth #1969 and learn more about how we’re enabling modern application delivery
Learn more about the Docker Kubernetes Service

The post Don’t Pick an Ops Platform Your Devs Won’t Use appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Learn About Modern Apps with Docker at VMworld 2019

The Docker team will be on the show floor at VMworld the week of August 25. We’ll be talking about the state of modern application development, how to accelerate innovation efforts, and the role containerization and Docker play in powering these initiatives. 

Come by booth #1969 at VMworld to check out the latest developments in the Docker platform and learn why over 1.8 million developers build modern applications on Docker, and why over 800 enterprises rely on Docker Enterprise for production workloads. 

At VMworld, we’ll be talking about:

What’s New in Docker Enterprise 3.0

Docker Enterprise 3.0 shipped recently, making it the first and only desktop-to-cloud container platform in the market that lets you build and share any application and securely run them anywhere – from hybrid cloud to the edge. At VMworld, we’ll have demos that shows how Docker Enterprise 3.0 simplifies Kubernetes with the Docker Kubernetes Service (DKS) and enables companies to more easily build modern applications with Docker Desktop Enterprise and Docker Application.

Accelerating Your Journey to the Cloud

Everyone is talking about moving workloads to the cloud to drive efficiencies and simplify ops, but many existing applications that power enterprises still run in corporate datacenters. Cloud migration for existing apps is often thought to be a resource-intensive, arduous process, but that doesn’t have to be the case.

At VMworld, we’ll be demonstrating how we work with customers to provide an easy path to the cloud by identifying applications that are best-suited for containerization and automating the migration process. Applications that are modernized and containerized with Docker Enterprise are portable across public, private and hybrid clouds, so you don’t get locked-in to one provider or platform.  

Unifying the Dev to Ops Experience

There’s no question that modern, distributed applications are becoming more complex.  You need a seamless and repeatable way to build, share and run all of your company’s applications efficiently. A unified end-to-end platform addresses these challenges by improving collaboration, providing greater control and ensuring security across the entire application lifecycle.

With Docker Enterprise, your developers can easily build containerized applications without disrupting their existing workflows and IT ops can ship these new services faster with the confidence of knowing security has been baked in from the start – all under one unified platform. Talk to a Docker expert at VMworld about how Docker Enterprise provides the developer tooling, security and governance, and ease of deployment needed for a seamless dev to ops workflow. 

We hope to see you at the show! 

Learn how Docker helps you build modern apps and modernize your existing apps at #VMworld2019Click To Tweet

Want a preview? Watch the Docker Enterprise 3.0 demo.

Dive deeper with the following resources: 

See what’s new in Docker Enterprise 3.0 Get started with a free trial of Docker Enterprise 3.0Watch the webinar series: Drive High-Velocity Innovation with Docker Enterprise 3.0

The post Learn About Modern Apps with Docker at VMworld 2019 appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Developing Docker-Powered Applications on Windows with WSL 2

This is a guest post from Docker Captain Antonis Kalipetis, a Senior Software Engineer at e-food — the leading online food delivery service in Greece. He is a Python lover and developer and helps teams embrace containers and improve their development workflow. He loves automating stuff and sharing knowledge around all things containers, DevOps and developer workflows. You can follow him on Twitter @akalipetis.

WSL 2 (or Windows Subsystem for Linux version 2) is Microsoft’s second take on shipping a Linux Kernel with Windows. The first version was awesome as it translated Linux system calls to the equivalent Windows NT call in real time. The second version includes a full fledged virtual machine. 

It was only natural that Docker would embrace this change and ship a Docker Desktop for Windows version that runs on WSL 2 (WSL 1 had issues running the Docker daemon). This is still a Technical Preview, but after using it for a couple of days, I’ve completely switched my local development to take advantage of it and I’m pretty happy with it.

In this blog, I’ll show you an example of how to develop Docker-powered applications using the Docker Desktop WSL 2 Tech Preview.

Why use Docker Desktop WSL 2 Tech Preview over the “stable” Docker Desktop for Windows?

The main advantage of using the technical preview is that you don’t have to manage your Docker VM anymore.  More specifically:

The VM grows and shrinks with your needs in terms of RAM/CPU, so you don’t have to decide its size and preallocate resources., It can shrink to almost zero CPU/RAM if you don’t use it. It works so well that most of the time you forget there’s a VM involved.Filesystem performance is great, with support for inotify and the VM’s disk size can match the size of your machine’s disk.

Apart from the above, if you love Visual Studio Code like I do, you can use the VS Code Remote WSL plugin to develop Docker-powered applications locally (more on that in a bit). You also get the always awesome Docker developer experience while using the VM.

How does Docker Desktop for WSL 2 Tech Preview work?

When you install it, it automatically installs Docker in a managed directory in your default WSL 2 distribution. This installation includes the Docker daemon, the Docker CLI and the Docker Compose CLI. It is kept up to date with Docker Desktop and you can either access it from within WSL, or from PowerShell by switching contexts — see, Docker developer experience in action!

Developing applications with Docker Desktop for WSL 2 Tech Preview

For this example, we’ll develop a simple Python Flask application, with Redis as its data store. Every time you visit the page, the page counter will increase — say hello to Millennium!

Setting up VS Code Remote – WSL

Visual Studio Code recently announced a new set of tools for developing applications remotely — using SSH, Docker or WSL. This splits Visual Studio Code into a “client-server” architecture, with the client (that is the UI) running on your Windows machine and the server (that is your code, Git, plugins, etc) running remotely. In this example, we’re going to use the WSL version.

To start, open VS Code and select “Remote-WSL: New Window”. This will install the VS Code Remote server in your default WSL distribution (the one running Docker) and open a new VS Code workspace in your HOME directory.

Getting and Exploring the Code

Clone this Github repository by running git clone https://github.com/akalipetis/python-docker-example. Next, run code -r python-docker-example to open this directory in VS Code and let’s go a quick tour!

Dockerfile and docker-compose.yml

These should look familiar. The Dockerfile is used for building your application container, while docker-compose.yml is the one you could use for deploying it. docker-compose.override.yml contains all the things that are needed for local development.

Pipfile and Pipfile.lock

These include the application dependencies. Pipenv is the tool used to manage them.

The app.py  file contains the Flask application, which we’re just using in this example. Nothing special here!

Running the application and making changes

In order to run the application, open a WSL terminal (this is done using the integrated terminal feature of VS Code) and run docker-compose up. This will start all the containers (in this case, a Redis container and the one running the application). After doing so, visit http://localhost:5000 in your browser and voila — you’ve visited your new application. That’s not development though, so let’s change and see it in action. Open the app.py in VS Code and change the following line:

Refresh the web page and observe that:

The message was immediately changedThe visit counter continued counting from the latest value

Under the hood

Let’s see what actually happened.

We changed a file in VS Code, which is running on Windows.Since VS Code is running on a client-server mode with the server running is WSL 2, the change was actually made to the file living inside WSL.Since you’re using the Technical Preview of Docker Desktop for WSL 2 and docker-compose.override.yml is using Linux workspaces to mount the code from WSL 2 directly into the running container, the change was propagated inside the container.While this is possible with the “stable” Docker Desktop for Windows, it isn’t as easy. By using Linux workspaces, we don’t need to worry about file system permissions. It’s also super fast, as it’s a local Linux filesystem mount.Flask is using an auto-reloading server by default, which — using <code>inotify</code> — is reloading the server on every file change and within milliseconds from saving your file, your server was reloaded.Data is stored in Redis using a Docker volume, thus the visits counter was not affected by the restart of the server.

Other tips to help you with Docker Desktop for WSL 2

Here are a few additional tips on developing inside containers using the Technical Preview of Docker Desktop for WSL 2:

For maximum file system performance, use Docker volumes for your application’s data and Linux Workspaces for your code.To avoid running an extra VM, switch to Windows containers for your “stable” Docker Desktop for Windows environment.Use docker context and default|wsl to switch contexts and develop both Windows and Linux Docker-powered applications easily.

Final Thoughts

I’ve switched to Windows and WSL 2 development for the past two months and I can’t describe how happy I am with my development workflow. Using Docker Desktop for WSL 2 for the past couple of days seems really promising, and most of the current issues of using Docker in WSL 2 seem to be resolved. I can’t wait for what comes next!

The only thing currently missing in my opinion is integration with VS Code.  Remote Containers (instead of Remote WSL which was used for this blogpost) would allow you to run all your tooling within your Docker container.

Until VS Code Remote Containers support is ready, you can run pipenv install –dev to install the application dependencies on WSL 2, allowing VS Code to provide auto-complete and use all the nice tools included to help in development.

Get the Technical Preview and Learn More

If you’d like to get on board, read the instructions and install the technical preview from the Docker docs.

For more on WSL 2, check out these blog posts:

5 Things to Try with Docker Desktop WSL 2 Tech PreviewGet Ready for the Tech Preview of Docker Desktop for WSL 2

The post Developing Docker-Powered Applications on Windows with WSL 2 appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Deploying Dockerized .NET Apps Without Being a DevOps Guru

This is a guest post by Julie Lerman. She is a Docker Captain, published author, Microsoft Regional Director and a long-time Microsoft MVP who now counts her years as a coder in decades. She makes her living as a coach and consultant to software teams around the world. You can follow Julie on her blog at thedatafarm.com/blog, or on Twitter at @julielerman.

.NET Developers who use Visual Studio have access to a great extension to help them create Docker images for their apps. The Visual Studio Tools for Docker simplify the task of developing and debugging apps destined for Docker images. But what happens when you are ready to move from debugging in Visual Studio to deploying your image to a container in the cloud?

This blog post will demonstrate first using the tooling to publish a simple ASP.NET Core API in an image to the Docker hub, and then creating a Linux virtual machine in Azure to host the API. It will also engage Docker Compose and Microsoft SQL Server for Linux in a Docker container, along with a Docker Volume for persistence. The goal is to create a simple test environment and a low-stress path to getting your first experience with publishing an app in Docker.

Using the Docker Tools to aid in building and debugging the API is the focus of a series of articles that were published in the April, May and June 2019 issues of MSDN Magazine. So I’ll provide only a high level look at the solution.

Overview of the Sample App

The API allows me to track the names of Docker Captains. It’s not a real-world solution, but enough to give me something to work with. You can download the solution from github.com/julielerman/dockercaptains. I’ll provide a few highlights here.

public class Captain
{
public int CaptainId { get; set; }
public string Name { get; set; }
}

The API leverages Entity Framework Core (EF Core) for its data persistence. This requires a class that inherits from the EF Core DbContext. My class, CaptainContext, specifies a DbSet to work from and defines a bit of seed data for the database.

Enabling a Dynamic Connection String

The startup.cs file uses ASP.NET Core’s dependency injection to configure a SQL Server provider for the CaptainContext. There is also code to read a connection string from an environment variable within the Docker container and update a password placeholder that’s less visible to prying eyes.

public void ConfigureServices(IServiceCollection services)
{
services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);
var conn = Configuration[“ConnectionStrings:CaptainDB”];
conn = connectionstring.Replace(“ENVPW”, Configuration[“DB_PW”]);
services.AddDbContext<CaptainContext>(options => options.UseSqlServer(conn));
}

The VS Tools generated a Dockerfile and I only made one change to the default — adding the CaptainDB connection string ENV variable with its ENVPW placeholder:

ENV ConnectionStrings:CaptainDB “Server=db;Database=CaptainDB;User=sa;Password=ENVPW;”

ASP.NET Core can discover Docker environment variables when running in a Docker container.

Orchestrating with a docker-compose file

Finally comes the docker-compose.yml file. This sets up a service for the API image, another for the database server image and a volume for persisting the data.

version: ‘3.4’

services:
dataapidocker:
image: ${DOCKER_REGISTRY-}dataapidocker
build:
context: .
dockerfile: DataAPIDocker/Dockerfile
environment:
– DB_PW
depends_on:
– db
ports:
– 80:80
db:
image: mcr.microsoft.com/mssql/server
volumes:
– mssql-server-julie-data:/var/opt/mssql/data
environment:
SA_PASSWORD: “${DB_PW}”
ACCEPT_EULA: “Y”
ports:
– “1433:1433″
volumes:
mssql-server-julie-data: {}

Notice that I’m declaring the DB_PW environment variable in the API’s service definition and referencing it in the db’s service definition.

There’s also an .env file in the solution where the value of DB_PW is hidden.

DB_PW=P@ssword1

Docker will read that file by default. I go into more detail about the .env file on my blog. 

I got this solution set up and running from within Visual Studio on my development machine. And I love that even when the debugger publishes the app to a local container, I can still debug while it’s running in that container. That’s a super-power of the tools extension.

Using the Tools to Publish to Docker Hub

Once I was happy with my progress, I wanted to get this demo running in the cloud.  Although I can easily use the CLI to push and pull, I love that the Docker Tools in VS can handle this part. The Dockerfile created by the tool has instructions for a multi-stage build. When you target Visual Studio to a release build, the tools will build the release image described in the Dockerfile. Publishing will rebuild that release image and publish it to your destination registry.

You can see my full solution in the screenshot below. My API project is called DataAPIDocker. Notice there is also a docker-compose project. This was created by the Docker Tools.  But it is the DataAPIDocker project that will be published first into an image and then to a repository.

This will present a Publish page where you can choose to create a New Profile. A publish profile lets you define where to publish your app and also predefine any needed credentials. Creating a profile begins with selecting from a list of targets; for publishing a Docker image, select Container Registry. That option then gives you predefined registries to choose, such as Azure Container Registry, Docker Hub,  or a custom registry – which could be an instance of Docker Trusted Registry. 

I’ll choose Docker Hub and click Publish. 

The last step is to provide your Docker Hub repository name. If you don’t already have docker.config set up with your credentials, then you also need to supply your password. 

After creating a profile, it gets stored in the Visual Studio project.

You’ll be returned to the Publish overview page with this profile selected, where you can edit the default “latest” tag name. Click the Publish button to trigger the Docker Tools to do their job. 

A window will open up showing the progress of the docker push command run by the tools.

After the push is complete you can open the repository to see your new repository which by default is public.

Setting up an Azure Linux VM to Host the Containers

Now that the image is hosted in the cloud, you can turn your sights to hosting a container instance for running the app. Since my Visual Studio Subscription includes credits on Azure, I’ll use those.  I will create a Linux Virtual Machine on Azure with Docker and Docker Compose, then run an instance of my new image along with a SQL Server and a data volume.

I found two interesting paths for doing this at the command line. One was by using the Azure CLI at the command line in Windows, macOS or Linux. It is so much easier than doing it through the Azure Portal.

I found this doc to be really helpful as I was doing this for the first time. The article walks you through installing the Azure CLI, logging into Azure, creating a Linux VM with Docker already installed then installing Docker Compose. Keep in mind that this will create a default machine using “Standard DS1 v2 (1 vcpus, 3.5 GB memory)” setup. That VM size has an estimated cost of about $54 (USD) per month. 

Alternatively, you can use Docker Machine, a Docker tool for installing Docker on virtual hosts and managing the hosts. This path is a little more automated but it does require that you use bash and that you start by using the Azure CLI to log into your Azure account using the command az login.

Once that’s done, you can use parameters of docker-machine to tell it you’re creating  this in Azure, specify your subscription, ssh username, port and size of the machine to create. The last uses standard Azure VM size names. 

I found it interesting to use the Azure CLI workflow which was educational and then consider the docker-machine workflow as a shortcut version.

Since I was still working on my Windows machine, and don’t have the Windows Subsystem for Linux installed there, I opened up Visual Studio Code and switched my terminal shell to use bash.  That let me use docker-machine without issue.I also have the Azure Login extension in VS Code, so I was already logged in to Azure.

I first had to get the subscription ID of my Azure Account which I did using the CLI. Then I plugged the id into the docker-machine command:

docker-machine create -d azure
–azure-subscription-id [this is where I pasted my subscript id]
–azure-ssh-user azureuser
–azure-open-port 80
–azure-size “Standard_DS1_v2″
mylinuxvm

There are more settings you can apply, such as defining the resource and location. The output from this command will pause, providing you with details for how to allow docker-machine authorization to the VM by plugging a provided code into a browser window.  Once that’s done the command will continue its work and the output will forge ahead.

When it’s finished, you’ll see  the message “Docker is up and running!” (on the new VM), Followed by a very important message to configure a shell on the VM by running:

“C:Program FilesDockerDockerResourcesbindocker-machine.exe” env mylinuxvm

Recall that I’m doing these tasks on Windows, so docker-machine is ensuring that I know where to find the executable. After performing this task, I can see the machine up and running in the Azure Portal. This lets me inspect other default configuration choices made because I didn’t specify them in the docker-machine command.

By default, all of the needed ports are set up for access such as 80 for http and 22 for ssh.

Re-Creating Docker-Compose and .env on the VM

We only need two files on this machine: the docker-compose.yml and the .env file.

Docker-machine allows you to easily ssh into the VM in order for your command line commands to execute on that machine.

docker-machine ssh mylinuxvm

Then you can use a linux editor such as nano to re-create the two files.

nano docker-compose.yml

And you can paste the contents of your docker-compose file into there. This is the docker-compose file in my solution for the sample app. However, there are two edits you’ll need to make.

The original file depends on a variable supplied by the VS Docker Tools for the registry location. Change the value of image to point to your Docker Hub image: image: julielerman/dataapidocker:formylinuxvmYou’ll also need to change the version of docker-compose specified at the top of the file to 2.0 since you’re moving from hosting on Windows to hosting on Linux.

In nano, you can save the docker-compose file with ^O. Then exit nano and run it again to create the .env file using the command:

nano .env

Paste the key value pair environment variable from the app and save the .env file.

Running the Container

I still had to install docker-compose on the new machine. Docker is nice enough to feed you the command for that if you try to run docker-compose before installing it.
sudo apt install docker-compose

Then I was able to run my containers with: sudo docker-compose up

One important thing I learned: The VS Docker tooling doesn’t define port mapping for the API service in docker-compose. That’s hidden in a docker-compose.override.yml file used by the debugger. If you look at the docker-compose file listed earlier in this article, you’ll see that I added it myself. Without it, when you try to browse to the API, you will get a Connection refused error.

My ASP.NET Core API is now running and I can browse to it at public IP address specified for the VM. The HTTP Get of my Captains controller returns a list of the captains seeded in the database. 

DevOps are for Devs, Too

As a developer who is often first in line to claim “I don’t do DevOps”, I was surprised at how simple it turned out to be to deploy the app I had created. So often I have allowed my development machine to be a gate that defined the limitations of my expertise. I can build the apps and watch them work on my development machine but I’ve usually left deployment to someone else.

While I have ventured into the Azure Portal frequently, the fact that the Docker Tools and the Azure CLI made it so simple to create the assets I needed for deploying the app made me wonder why I’d waited so long to try that out. And in reality, I didn’t have to deploy the app, just an image and then a docker-compose file. That the Docker Machine made it even easier to create those cloud assets was something of a revelation. 

Part of this workflow leveraged the Docker Tools for Visual Studio on Windows. But because I spend a lot of time in Visual Studio Code on my MacBook, I now have the confidence to explore using the Docker CLI for publishing the image to Docker Hub. After that I can just repeat the Docker Machine path to create the Azure VM where I can run my containers. 

If you want to learn more, these posts and articles are a great place to start:

5 Things to Try with Docker Desktop WSL 2 Tech Preview Video Series: Modernizing .NET Apps for Developers EF Core in a Docker Containerized App (3 part series in MSDN Magazine)Julie’s blog posts on docker-compose and publishing Docker images to Azure

Get Started with Docker Desktop

How to Deploy Dockerized .NET Apps Without Being a DevOps Guru by #Docker Captain @julielermanClick To Tweet

The post Deploying Dockerized .NET Apps Without Being a DevOps Guru appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

See Docker Enterprise 3.0 in Action in Our Upcoming Webinar Series

Docker Enterprise 3.0 represents a significant milestone for the industry-leading enterprise container platform. It is the only end-to-end solution for Kubernetes and modern applications that spans from the desktop to the cloud.  With Docker Enterprise 3.0, organizations can build, share, and run modern applications of any language or technology stack, on their choice of infrastructure and operating system.

To showcase all of the capabilities of the platform and highlight what is new in this release, we invite you to join our 5-part webinar series to explore the technologies that make up Docker Enterprise 3.0. You’ll see several demos of the platform and gain a better understanding of how Docker can you help your organization deliver high-velocity innovation while providing you the choice and security you need. We designed the webinar both for those new to containers and Kubernetes, as well as those who are just here to learn more about what’s new. We’re excited to share what we’ve been working on.

Sign Up for the Series

Here’s an overview of what we’ll be covering in each session.

Part 1: Content Management

Tuesday, August 13, 2019 @ 11am PDT / 2pm EDT

This webinar will cover the important aspects of tracking the provenance of and  securing your container images.

Part 2: Security

Wednesday, August 14, 2019 – 11am PDT / 2pm EDT

Learn how Docker Enterprise uses a multi-layered approach to security in delivering a secure software supply chain. 

Part 3: Docker Applications

Thursday, August 15, 2019 @ 11am PDT / 2pm EDT

Find out how you can accelerate developer productivity with the use of application templates and Docker Applications – a new way to define multi-service applications based on the CNAB specification.

Part 4: Operations Management

Tuesday, August 20, 2019 – 11am PDT / 2pm EDT

Discover how Docker Enterprise makes Day 1 and Day 2 operations simple and repeatable.

Part 5: Docker Kubernetes Service

Wednesday, August 21, 2019 – 11am PDT / 2pm EDT

See how Docker Kubernetes Service (DKS) makes Kubernetes easy to use and more secure for the entire organization.

Register for our upcoming 5-part #webinar series to see #Docker Enterprise 3.0 in action:Click To Tweet

To learn more about Docker Enterprise 3.0:

Register for the webinar seriesTest drive Docker Enterprise 3.0 with a free, hosted trial

The post See Docker Enterprise 3.0 in Action in Our Upcoming Webinar Series appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

5 Things to Try with Docker Desktop WSL 2 Tech Preview

We are pleased to announce the availability of our Technical Preview of Docker Desktop for WSL 2! 

As a refresher, this preview makes use of the new Windows Subsystem for Linux (WSL) version that Microsoft recently made available on Windows insider fast ring. It has allowed us to provide improvements to file system sharing, boot time and access to some new features for Docker Desktop users. 

To do this we have changed quite a bit about how we interact with the operating system compared to Docker Desktop on Windows today: 

To learn more about the full feature set have a look at our previous blog:   Get Ready for Tech Preview of Docker Desktop for WSL 2  and  Docker WSL 2 – The Future of Docker Desktop for Windows.

Want to give it a go?

Get setup on a Windows machine on the latest Windows Insider build. The first step for this is heading over to the Microsoft and getting set up as a Windows Insider: https://insider.windows.com/en-gb/getting-started/ You’ll need to install the latest release branch (at least build version 18932) and you will then want to enable the WSL 2 feature in Windows: https://docs.microsoft.com/en-us/windows/wsl/wsl2-installThen get Ubuntu 18.04 on your machine: Microsoft store. Finally, download the Tech Preview  Docker Desktop for WSL 2 Technical Preview

If you are having issues or want more detailed steps, have a look at our docs here.

Things to try:

Navigate between WSL 2 and traditional Docker

Use $ docker context ls  to view the different contexts available.

The daemon running in WSL 2 runs side-by-side with the “classic” Docker Desktop daemon. This is done by using a separate Docker Context. Run `docker context use wsl` to use the WSL 2 based daemon, and `docker context use default` to use the Docker Desktop classic daemon. The “default” context will target either the Moby Linux VM daemon or the Windows Docker daemon depending if you are in Linux or Windows mode. 

Access full system resources

Use $ docker info to inspect the system statistics. You should see all of your system resources (CPU & memory) available to you in the WSL 2 context. 

Linux workspaces

Source code and build scripts can live inside WSL 2 and access the same Docker Daemon as from Windows. Bind mounting files from WSL 2 is supported, and provides better I/O performance.

Visual Studio remote with WSL

You can work natively with Docker and Linux from Visual Studio Code on Windows. 

If you are a Visual Studio Code user make sure you have installed the plugin from the marketplace. You can then connect to WSL 2 and access your source in Linux, which means you can use the console in VSCode to build your containers using any existing Linux build scripts from within the Windows UI.

For full instructions have a look through Microsoft’s documentation: https://code.visualstudio.com/docs/remote/wsl

File system improvements: 

If you are a PHP Symfony user let us know your thoughts! We found that page refreshes went from ~400ms to ~15ms when we were running from a Linux Workspace.

Want to Learn More?

Read more about the Docker Desktop for WSL 2 Technical PreviewLearn more about Docker Desktop and the new Docker Desktop EnterpriseLearn more about running Windows containers in this On-Demand webinar: Docker for Windows Container Development

5 Things to Try with #Docker Desktop WSL 2 Tech PreviewClick To Tweet

The post 5 Things to Try with Docker Desktop WSL 2 Tech Preview appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/