PWA Docker development

Transcript

Today I’ll be showing you how to run PWA inside of a Docker container for local developments, which will include having HTTPS support. So the requirements for running PWA inside of a Docker container are first that you need to install Docker. So first go to docs.docker.com slash install and make sure that you find the OS compatible version of Docker. There are Windows, Mac and Linux support and you should download the one specific for your computer. Secondly we also have a dependency on node and yarn. This is not for running Docker specifically but for the certification creation. We are reusing a library that is already used within PWA studio project called Devcert which is a node library and we are using yarn to install. So Docker, node and yarn. And fourth of all you need to be able to clone. So you need to have Git on your computer. So we need you to git clone the repository listed here in number two. So git clone the Magento Research PWA project. And a note to Windows users when you are installing Docker is to ensure that you have shared drives enabled. This will help because we are going to be doing hot reloading which we will be mapping our drives, our local file system to the Docker container. So we will need to make sure that that is enabled.

Now the only thing that you need in order to run Docker, PWA inside of Docker is this Docker slash run Docker script. And then once we run the script which I will show next, the script will go through and set up the environment variables needed, the host name for you, the certifications for that host. So that and the local trust on your computer with the browser for this particular domain. And we will see it running at this default domain that is set up PWA dash Docker dot localhost. So let’s just see that happening. So we start fresh in our PWA project and I am going to run the Docker slash run Docker script. Now what this is doing is it is going through and copying over an environment variable file that is the default variables that are set up in order to support the PWA project to a dot env file. This will be consumable by Docker compose and make it easier to move the environment variables around. Printing out the environment variables being used. Now these are all set in this default file for you and then copied over to be used inside of the container. We will be going through some of the details of what those environment variables are a little bit later. But let’s just go through and just see the application running first. So we are creating a certificate with Dev cert. It is being created per domain that is being used. So right now the setup is for the default PWA dash Docker dot localhost. And then we’re going through the process of building the image from our Docker file. Going through and copying over just the files needed for the build. Doing a yarn install and copying over the rest of the files. That is to utilize the Docker cache. I’ll go through that a little bit as we go through some of these scripts. And then we’re actually running the build. And then eventually running the script that is our Vennia concept run watch task with our particular host that we have enabled. The run Docker script will also run the Docker commands for you. So it will start the Docker network and the containers. And then it will run the Docker script. And at the end of it, you end up with a container that is running your PWA application over HTTPS for your specific host. Now we start this up. We see that the PWA project is running. Default project. We can click on accept. And then we can go to the next project. While all running in our Docker container. So these are all of the requests that are being proxy through nginx to our Docker container. And then we can go through and update the workflow. So we can see that we have a workflow that is running. Running in our Docker container. So these are all of the requests that are being proxy through nginx to our Docker container. Now by default, the default setup utilizes this configuration file with all the environment variables in it. The default backend URL is one that we are hosting and provide to the community in order for them and you all to easily be able to start up and see the PWA product running. The default host domain is the PWA Docker.localhost, which is configurable as well as this port that we are running the application on. And by default, the service workers are disabled. By disabling service workers, we allow for the hot reloading in development mode to work a little bit more seamlessly.

So here I am going to show you how the hot reloading is working. So we start off with our CMS page is Shop by category. That is our main Shop by category page. I’m just going to change this to cats. It’s just two cats. And when I come back over here, we see that it is refreshing and it updates to cats immediately.

Just showing you that the service workers are disabled by default. Now when we enable service workers, we’ll want to be clicking this update on reload option if you are wanting to see the hot reloading working while also enabling service workers. And this is not unique to Docker. This is more unique to how service workers are working. The service worker files will not reload unless you tell them to reload, which is really only an issue if you are working locally. To on service workers and or just development mode and ideally hot hot reloading is only for development. So you may not need service workers enabled while you are developing. But let’s say that I wanted to do some custom setup here. So what are the custom values that we can set up here? Custom values are all going to be mapped in this .m.docker.dev file. So let’s just copy over that file.

And let’s just put it, I’m going to put it in the same location and I’m just going to call it sharks. Let’s do sharky sharks. So now we have this other file here and I’m just going to change this to be sharkysharks.localhost. You can change that to whatever you like, whatever your application is running on. And my application is still running on 8080, but if my port was different, I would switch that. And this time I’m going to enable service workers. Be able to see them working and running. And I’m not going to enable polling though if your computer is not working with the typical watch task, then you can enable polling. And this is something that the Webpack dev server also suggests that some systems might not be working with regular watch tasks. And you can enable polling if you want. Just a note that polling is CPU intensive, so it might not be something that you want to run all the time. But if you need it, it’s not working on your computer. By all means, use the polling. And then you can configure your own backend URL with whatever you have running, or you can use ours just as a demo purpose. The rest of these values can be found, more details on those values can be found under the packages. Then the concept.m.dist file. This is where you can have all sorts of information about the different environment variables that you can set. But these are the ones that we won’t really be manipulating these for our own purposes. And then the other one is the environment variables. And this is where you can have all sorts of information about the different environment variables that you can set. These are the ones that we won’t really be manipulating these for our purposes right now. So I’ve changed this now, and now I want to run the Docker, run Docker task script, dash e flag, and then point it to my specific file that I have my configuration at. And when I run it now, you can see that it says that the configuration being used is from this particular environment variable file that I passed in. And we can see that those environment variables have been specifically set here with my sharkysharks.localhost. And every time you run the Docker run Docker task, it’s going to be asking you for your password, your system password in order for Dev cert to be able to set up a certification trust between your computer and the browser for this domain that is running for the application running through the NGINX layer in our Docker compose setup. So, So it is showing that the, I messed up my password the first time, but we have been able to set up a certificate for this specific, this specific domain. So we can see that set up here in the certs folder underneath Docker. This is where the certs end up living. So the first time I wasn’t asked for my password because I already had the default certification for that here. But when I set up my new one, I was able to see it and all of the items here in the search. Now I’m going to delete those search afterwards. So don’t worry if you’re able to screenshot that or anything. But this is just for my local setup. So it is running through again, building the image, but on the second time you build the image. After the first time, it is going to be looking in the Docker cache for all of the different image layers that you may have created. So if there are no changes in the layer, meaning every run task, every from each one of these steps are creating an image layer. Now if you have not changed any of the items, any of the information within that layer, then it’s going to use cache. And the cache works from top down. So if a layer has been changed high up in the steps, then every subsequent layer will not use cache and will build fresh. So the idea here is the Docker file has been created so that all the layers towards the top of the file are not supposed to change as frequently as some of the items at the lower half of the file. Packages, if you make a change to any of the files under packages, which is the main folder for the project, then every subsequent layer after that will be set up fresh. So that’s just a side note to how the Docker cache works and some of the logic behind how the Docker file is set up for this project. But it is going through and running a run build task again as it did before, and it is then going to copy over all of the files from the previous step into the second step. And again, we’re running through here and we are starting the Docker container.

Let’s wait for this to come up. And now we see that the project is running over https at sharkysharks.localhost. So click that and we’re going over here and we will be seeing the application running shortly. And we look in our service workers.

Just take a second to come up. When we look at our service workers, the service worker has been enabled for this site. So now we can see the service worker is actually running.

Still shopping by cats because I changed that from our previous step. And I’m going to click the update on reload to show you how the cache is working.

How rather not the cache, but the pot reloading is working. So I said, shop by dinosaurs. Come over here. We see that it updates and says shop by dinosaurs. And this is working with the service worker. So if you have to do some service working debugging for any reason, the service worker is enabled and you can see it running. Again, all of the requests are being proxied through our nginx layer. And we can see the part where this is the part where the recompiling works from webpack when it notices a change over the watch task.

So that’s the main functionality that is provided with the run Docker script. You are able to set a custom domain inside and provide. You can set your own custom domain with your own custom environment file and pass it to the run task. Or you can modify the existing default values in the .m.docker.dev file. You are able to enable service workers or enable polling if you like. You are also able to change the port that is running at as well as the backend URL. And all of these values are configurable. So if you have your own brain tree token, you want to use that here. And again, look at the packages, venea-concept.m.dist file for more details on different environment variables that you can set for your project. Briefly, I will go over what is going on in the Dockerfile.dev and the Docker Compose to close out this demo. So the Dockerfile that we’ve been watching run, again, a little bit cleaner to see it in its actual file, is using the node-alpine base image. Setting a working directory to the app, installing some dependencies for the system, and then copying over only the files needed for doing the install and the build task. So all of the build task items are being set, just the items needed for install and then copying over all the packages needed for the build step. This is to utilize the Docker cache more, encourage you to look up how the Docker cache is working on the interwebs. And I’m utilizing a multi-stage build here to separate the build steps from the run task and setting up the default user that comes with Alpine, the node user, to have ownership over the file, over the whole application folder, and to be able to run the watch task for our particular host. The Docker Compose file is what is doing the mapping over of the certs folder into the container, so our certs are available inside of the container, and is also allowing us to, in this volume section, this is what is we’re mapping over all of the different files and folders that we need to be able to enable for the build. So the particular files and folders are mapped over, so if there is some folder or file that you need to be able to use with hot reloading, this is where you would add it. You would add another line below this to the particular file that you need. These are just most of the files that will be used during the hot reloading. And you’ll also want to make sure that the hot reloading is working with Webpack for those particular files.

And that concludes how to run PWA inside of a Docker container over HTTPS.