Getting Started with Docker Using Node – Part II

In part I of this series, we learned about creating Docker images using a Dockerfile, tagging our images and managing images. Next we took a look at running containers, publishing ports, and running containers in detached mode. We then learned about managing containers by starting, stopping and restarting them. We also looked at naming our containers so they are more easily identifiable.

In this post, we’ll focus on setting up our local development environment. First, we’ll take a look at running a database in a container and how we use volumes and networking to persist our data and allow our application to talk with the database. Then we’ll pull everything together into a compose file which will allow us to setup and run a local development environment with one command. Finally, we’ll take a look at connecting a debugger to our application running inside a container.

Local Database and Containers

Instead of downloading MongoDB, installing, configuring and then running the Mongo database as a service. We can use the Docker Official Image for MongoDB and run it in a container.

Before we run MongoDB in a container, we want to create a couple of volumes that Docker can manage to store our persistent data and configuration. I like to use the managed volumes feature that docker provides instead of using bind mounts. You can read all about volumes in our documentation.

Let’s create our volumes now. We’ll create one for the data and one for configuration of MongoDB.

$ docker volume create mongodb

$ docker volume create mongodb_config

Now we’ll create a network that our application and database will use to talk with each other. The network is called a user defined bridge network and gives us a nice DNS lookup service which we can use when creating our connection string.

docker network create mongodb

Now we can run MongoDB in a container and attach to the volumes and network we created above. Docker will pull the image from Hub and run it for you locally.

$ docker run -it –rm -d -v mongodb:/data/db

-v mongodb_config:/data/configdb -p 27017:27017

–network mongodb

–name mongodb

mongo

Okay, now that we have a running mongodb, let’s update server.js to use a the MongoDB and not an in-memory data store. 

const ronin     = require( ‘ronin-server’ )

const mocks     = require( ‘ronin-mocks’ )

const database  = require( ‘ronin-database’ )

const server = ronin.server()

database.connect( process.env.CONNECTIONSTRING )

server.use( ‘/’, mocks.server( server.Router(), false, false ) )

server.start()

We’ve add the ronin-database module and we updated the code to connect to the database and set the in-memory flag to false. We now need to rebuild our image so it contains our changes.

First let’s add the ronin-database module to our application using npm.

$ npm install ronin-database

Now we can build our image.

$ docker build –tag node-docker .

Now let’s run our container. But this time we’ll need to set the CONNECTIONSTRING environment variable so our application knows what connection string to use to access the database. We’ll do this right in the docker run command.

$ docker run

-it –rm -d

–network mongodb

–name rest-server

-p 8000:8000

-e CONNECTIONSTRING=mongodb://mongodb:27017/yoda_notes

node-docker

Let’s test that our application is connected to the database and is able to add a note.

$ curl –request POST

  –url http://localhost:8000/notes

  –header ‘content-type: application/json’

  –data ‘{

“name”: “this is a note”,

“text”: “this is a note that I wanted to take while I was working on writing a blog post.”,

“owner”: “peter”

}’

You should receive the following json back from our service.

{“code”:”success”,”payload”:{“_id”:”5efd0a1552cd422b59d4f994″,”name”:”this is a note”,”text”:”this is a note that I wanted to take while I was working on writing a blog post.”,”owner”:”peter”,”createDate”:”2020-07-01T22:11:33.256Z”}}

Using Compose to Develop locally

Awesome! We now have our MongoDB running inside a container and persisting it’s data to a Docker volume. We also were able to pass in the connection string using an environment variable.

But this can be a little bit time consuming and also difficult to remember all the environment variables, networks and volumes that need to be created and set up to run our application. 

In this section, we’ll use a Compose file to configure everything we just did manually. We’ll also set up the Compose file to start the application in debug mode so that we can connect a debugger to the running node process.

Open your favorite IDE or text editor and create a new file named docker-compose.dev.yml. Copy and paste the below commands into that file.

version: ‘3.8’

services:

 notes:

   build:

     context: .

   ports:

     – 8000:8000

     – 9229:9229

   environment:

     – CONNECTIONSTRING=mongodb://mongo:27017/notes

   volumes:

     – ./:/code

   command: npm run debug

 mongo:

   image: mongo:4.2.8

   ports:

     – 27017:27017

   volumes:

     – mongodb:/data/db

     – mongodb_config:/data/configdb

 volumes:

   mongodb:

   mongodb_config:

This compose file is super convenient because now we do not have to type all the parameters to pass to the docker run command. We can declaratively do that in the compose file.

We are exposing port 9229 so that we can attach a debugger. We are also mapping our local source code into the running container so that we can make changes in our text editor and have those changes picked up in the container.

One other really cool feature of using a compose file, is that we have service resolution automatically set up for us. So we are now able to use “mongo” in our connection string. The reason we can use “mongo” is because this is the name we used in the compose file to label our container running our MongoDB.

To be able to start our application in debug mode, we need to add a line to our package.json file to tell npm how to start our application in debug mode.

Open the package.json file and add the following line to the scripts section.

“debug”: “nodemon –inspect=0.0.0.0:9229 server.js”

As you can see we are going to use nodemon. Nodemon will start our server in debug mode and also watch for files that have changed and restart our server. Let’s add nodemon to our package.json file.

$ npm install nodemon

Let’s first stop our running application and the mongodb container. Then we can start our application using compose and confirm that it is running properly.

$ docker stop rest-server mongodb

$ docker-compose -f docker-compose.dev.yml up –build

If you get the following error: ‘Error response from daemon: No such container:’ Don’t worry. That just means that you have already stopped the container or it wasn’t running in the first place.

You’ll notice that we pass the “–build” flag to the docker-compose command. This tells Docker to first compile our image and then start it.

If all goes will you should see something similar:

Now let’s test our API endpoint. Run the following curl command:

$ curl –request GET –url http://localhost:8000/notes

You should receive the following response:

{“code”:”success”,”meta”:{“total”:0,”count”:0},”payload”:[]}

Connecting a Debugger

We’ll use the debugger that comes with the Chrome browser. Open Chrome on your machine and then type the following into the address bar.

about:inspect

The following screen will open.

Click the “Open dedicated DevTools for Node” link. This will open the DevTools window that is connected to the running node.js process inside our container.

Let’s change the source code and then set a breakpoint. 

Add the following code to the server.js file on line 9 and save the file. 

 server.use( ‘/foo’, (req, res) => {

   return res.json({ “foo”: “bar” })

 })

If you take a look at the terminal where our compose application is running, you’ll see that nodemon noticed the changes and reloaded our application.

Navigate back to the Chrome DevTools and set a breakpoint on line 10 and then run the following curl command to trigger the breakpoint.

$ curl –request GET –url http://localhost:8000/foo

BOOM You should have seen the code break on line 10 and now you are able to use the debugger just like you would normally. You can inspect and watch variables, set conditional breakpoints, view stack traces and a bunch of other stuff.

Conclusion

In this post, we ran MongoDB in a container, connected it to a couple of volumes and created a network so our application could talk with the database. Then we used Docker Compose to pull all this together into one file. Finally, we took a quick look at configuring our application to start in debug mode and connected to it using the Chrome debugger.

If you have any questions, please feel free to reach out on Twitter @pmckee and join us in our community slack.
The post Getting Started with Docker Using Node – Part II appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

ICYMI: From Docker Straight to AWS Built-in

In July we announced a new strategic partnership with Amazon to integrate the Docker experience you already know and love with Amazon Elastic Container Service (ECS) with AWS Fargate. Over the last couple of months we have worked with the community on the beta experience in Docker Desktop Edge. Today we are excited to bring this experience to our entire community in Docker Desktop stable, version 2.3.0.5.

You can watch Carmen Puccio (Amazon) and myself (Docker) and view the original demo in the recording of our latest webinar here.

What started off in the beta as a Docker plugin experience docker ecs has been pulled into Docker directly as a familiar docker compose flow.  This is just the beginning, and we could use your input so head over to the Docker Roadmap and let us know what you want to see as part of this integration. 

There is no better time to try it.  Grab the latest Docker Desktop Stable. Then check out my example application which will walk you through everything you need to know to deploy a Python application locally in development and then again directly to Amazon ECS in minutes not hours.

Want more? Join us this Wednesday, September 16th at 10am Pacific where Jonah Jones (Amazon), Peter McKee (Docker) and myself will continue the discussion on Docker Run, our YouTube channel. For a live QA from our last webinar. We will be answering the top questions from the webinar and from the live audience.

DockTalk Q&A: From Docker Straight to AWS

The post ICYMI: From Docker Straight to AWS Built-in appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Secure from the Start: Shift Vulnerability Scanning Left in Docker Desktop

Application delivery velocity can be tripped up when security vulnerabilities are discovered after an app is deployed into production. Nothing is more detrimental to shipping new features to customers than having to go back and address vulnerabilities discovered in an app or image you already released. At Docker, we believe the best way to balance the needs for speed and security is to shift security left in the app delivery cycle as an integral part of the development process. 

Integrating security checks into Docker Scan was the driver behind the partnership with Snyk, one of the leading app security scan providers in the industry. This partnership, announced in May of this year, creates a vision for a simple and streamlined approach for developers to build and deploy secure containers. And today, I’m excited to share that the latest Docker Desktop Edge release includes Snyk vulnerability scanning. This allows Docker users to trigger local Docker file and local image scans directly from the Docker Desktop CLI. With the combination of Docker Scan and Snyk, developers gain visibility into open source vulnerabilities that can have a negative impact on the security of container images. Now you can extend your workflow to include vulnerability testing as part of your inner development loop. Triggered from the Docker Desktop CLI, the Snyk vulnerability scans extend the existing, familiar process of vulnerability detection, and allow for remediation of vulnerabilities earlier in the development process. This process of simple and continuous checks leads to fewer vulnerabilities checked into Docker Hub, a shorter CI cycle, and faster and more reliable deployment into production. 

With that, let me show you how it works.

To begin, authenticated Docker users can start by running their scans by entering these Docker CLI commands –

To find their local image

$docker pull username/imageName

And run a scan

$docker scan username/imageName

The Docker scan CLI command supports several flags, providing options for running scans 

–exclude-base flag excludes base image vulnerabilities from the CLI scan results, allowing user to reduce the volume of reported vulnerabilities, and focus vulnerability reporting on their own image updates–json flag displays scan results in JSON format–dependency-tree flag provides the mapping of image dependencies before listing vulnerability data–f, –file flag indicates the location of the Dockerfile associated with the image, extending  vulnerability scanning results using the contents of the Dockerfile to further identify potential vulnerabilities across all the image manifests

You can also add multiple flags  in a single CLI command, for additional flexibility in consuming vulnerability data. Scans return scanned image data, including:

Vulnerability descriptionsVulnerability severitiesImage layer associated with the vulnerability,  including the Dockerfile command, if you’ve associated the Dockerfile with the scanExploit maturity, so you can easily identify which vulnerabilities have a known functioning exploitAvailable suggestions for remediation,  rebuilding if the base image is out-of-date, slimmer alternative images that can help reduce vulnerabilities, or package upgrades that resolve a vulnerability

Invoking scanning through Docker Desktop CLI allows you to iteratively test for new vulnerabilities, while working on image updates, by:

Making image updatesRunning a scan Discovering new vulnerabilities introduced with the latest updatesMaking more updates to remove these vulnerabilitiesConfirming vulnerability removal by running another scan

You can start taking advantage of this today in the latest release of Docker Desktop Edge.

After you download the new bits, you can get more comprehensive details on the scan functionality in the Docker documentation.

Finally, we have an upcoming webinar that takes you through the inner workings of the enhanced security capabilities in this new release. You can get more information and sign up for the webinar at this link. 

And stay tuned for further updates on triggering vulnerability scans from the Docker Hub.  

Next steps:

Download the latest version of the Desktop Edge releaseReview the Docker documentation Attend the webinar on Thursday, September 24 at 10:00am PT, Find and Fix Container Image Vulnerabilities with Docker and Snyk

Sign up for a free Snyk ID and Read the Snyk blog to learn more about the integration
The post Secure from the Start: Shift Vulnerability Scanning Left in Docker Desktop appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Check out the Azure CLI experience now available in Desktop Stable

Back in May we announced the partnership between Docker and Microsoft to make it easier to deploy containerized applications from the Desktop to the cloud with Azure Container Instances (ACI). Then in June we were able to share the first version of this as part of a Desktop Edge release, this allowed users to use existing Docker CLI commands straight against ACI making getting started running containers in the cloud simpler than ever. 

We are now pleased to announce that the Docker and ACI integration has moved into Docker Desktop stable 2.3.0.5 giving all Desktop users access to the simplest way to get containers running in the cloud. 

Getting started 

As a new starter, to get going all you will need to do is upgrade your existing Docker Desktop to the latest stable version (2.3.0.5), store your image on Docker Hub so you can deploy it (you can get started with Hub here) and then lastly you will need to create an ACI context to deploy it to. For a simple example of getting started with ACI you can see our initial blog post on the edge experience.

More CLI commands

We have added some new features since we first released the Edge experience, one of the biggest changes was the addition of the new docker volume command. We added this in as we wanted to make sure that there was an easy way to get started creating persistent state between spinning up your containers. It is always good to use a dedicated service for a database like Cosmo DB, but while you are getting started volumes are a great way to initial store state. 

This allows you to use existing and create new volumes, to get started with a new volume we can start by selecting our ACI context:

$ docker context use myaci 

Then we can create a volume in a similar way to the Docker CLI, though in this case we have a couple of cloud specific variables we do need to provide:

$ docker volume create –storage-account mystorageaccount –fileshare test-volume

Now I can use this volume either from my CLI:

docker run -v mystorageaccount/test-volume:/target/path myimage

Or from my Compose file:

myservice:
image: nginx
volumes:
– mydata:/mount/testvolumes

volumes:
mydata:
driver: azure_file
driver_opts:
share_name: test-volume
storage_account_name: mystorageaccount

Along with this the CLI now supports some of the most popular CLI commands that were previously missing including stop, start & kill.

Try it out

If you are after some ideas of what you can do with the experience you can check out Guilluame’s blog post on running Minecraft in ACI, the whole thing takes about ~15 minutes and is a great example of how simple it is to get containers up and running. 

Microsoft offers $200 of free credits to use in your first 30 days which is a great way to try out the experience, once you have an account you will just need Docker Desktop and a Hub repo with your images saved in and you can start deploying! 

To get started today with the new Azure ACI experience, download Docker Desktop 2.3.0.5 and try out the experience yourself. If you enjoy the experience, have feedback on it or other ideas on what Docker should be working on please reach out to us on our Roadmap.
The post Check out the Azure CLI experience now available in Desktop Stable appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Docker Talks Live Stream Monthly Recap

It’s time for a round up of Docker Talks, this time from the month of August. As you may remember, Chad Metcalf (@metcalfc) and I (@pmckee) started the weekly live-streaming video series to connect with you, our extended family of developers, and to help you succeed in your Docker journey.

In August, we held four sessions covering how to set up your local development environment with Node.js, Visual Studio remote debugging extension, the Awesome Compose project and common questions people have when starting with Docker. Below, I’ve put together the list of live streams for the month for your viewing and learning pleasure.

We live stream on our YouTube channel every Wednesday at 10 a.m. Pacific Time. You’ll find all of the past streams there and you can subscribe to get notifications. See you on the next live stream.

Docker Talks Live! Setting up your local development environment with Node.jsChad and I explore how to set up your local development environment with Node.js and debugging inside of containers. (Streamed live Aug. 5)

Docker Live! Debugging Node.js with VSCode Docker ExtensionI talk about Visual Studio remote debugging extension, do some light debugging of Node.js, inspect some containers and more. (Streamed live Aug. 12)

Docker Live! Awesome Compose and ECSChad dives into the Awesome Compose project, a repository containing a curated list of Compose application samples, and ECS, which lets users complete the journey from a local Docker Compose application to AWS. (Streamed live Aug. 19)

Docker Live! Getting Started Q&A.Chad and I go over Docker basics and common questions people have when starting with Docker. What’s an image? What’s a container? Can you use Docker on Windows? And so on. (Streamed live Aug. 26)

The post Docker Talks Live Stream Monthly Recap appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Welcome

kubernetes.dev – It is intended to be the hub for all things related to the Kubernetes Contributor experience. Who exactly is a contributor? We all are–Whether you’re writing docs, reviewing code, participating in th…
Quelle: news.kubernauts.io