WIP: Getting Started, improve deploy to cloud topics/UX of those steps (#4751)
* images to cover AWS deploy Signed-off-by: Victoria Bialas <victoria.bialas@docker.com> * added instructions on opening ports with security groups in AWS Signed-off-by: Victoria Bialas <victoria.bialas@docker.com> * finalized cloud deploy procedure, added info re: unset docker-machine variables Signed-off-by: Victoria Bialas <victoria.bialas@docker.com> * added screen snaps, cleanup, and iteration steps to cloud example Signed-off-by: Victoria Bialas <victoria.bialas@docker.com> * removed edge releases qualification on swarm connect from Desktop apps Signed-off-by: Victoria Bialas <victoria.bialas@docker.com> * added visualizer on cloud screen snap Signed-off-by: Victoria Bialas <victoria.bialas@docker.com> * moved iteration, cleanup step to be without CE steps in part 6 Signed-off-by: Victoria Bialas <victoria.bialas@docker.com>
After Width: | Height: | Size: 30 KiB |
After Width: | Height: | Size: 187 KiB |
After Width: | Height: | Size: 222 KiB |
After Width: | Height: | Size: 183 KiB |
After Width: | Height: | Size: 9.2 KiB |
After Width: | Height: | Size: 202 KiB |
After Width: | Height: | Size: 43 KiB |
After Width: | Height: | Size: 200 KiB |
|
@ -429,7 +429,9 @@ same `docker swarm join` command you used on `myvm2`, and capacity will be added
|
|||
to your cluster. Just run `docker stack deploy` afterwards, and your app will
|
||||
take advantage of the new resources.
|
||||
|
||||
## Cleanup
|
||||
## Cleanup and reboot
|
||||
|
||||
### Stacks and swarms
|
||||
|
||||
You can tear down the stack with `docker stack rm`. For example:
|
||||
|
||||
|
@ -445,6 +447,59 @@ docker stack rm getstartedlab
|
|||
> manager, but _you'll need this swarm for part 5, so please keep it
|
||||
> around for now_.
|
||||
|
||||
### Unsetting docker-machine shell variable settings
|
||||
|
||||
You can unset the `docker-machine` environment variables in your current shell
|
||||
with the following command:
|
||||
|
||||
```
|
||||
eval $(docker-machine env -u)
|
||||
```
|
||||
|
||||
This disconnects the shell from `docker-machine` created virtual machines,
|
||||
and allows you to continue working in the same shell, now using native `docker`
|
||||
commands (for example, on Docker for Mac or Docker for Windows). To learn more,
|
||||
see the [Machine topic on unsetting environment variables](/machine/get-started/#unset-environment-variables-in-the-current-shell).
|
||||
|
||||
### Restarting Docker machines
|
||||
|
||||
If you shut down your local host, Docker machines will stop running. You can check the status of machines by running `docker-machine ls`.
|
||||
|
||||
```
|
||||
$ docker-machine ls
|
||||
NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS
|
||||
myvm1 - virtualbox Stopped Unknown
|
||||
myvm2 - virtualbox Stopped Unknown
|
||||
```
|
||||
|
||||
To restart a machine that's stopped, run:
|
||||
|
||||
```
|
||||
docker-machine start <machine-name>
|
||||
```
|
||||
|
||||
For example:
|
||||
|
||||
```
|
||||
$ docker-machine start myvm1
|
||||
Starting "myvm1"...
|
||||
(myvm1) Check network to re-create if needed...
|
||||
(myvm1) Waiting for an IP...
|
||||
Machine "myvm1" was started.
|
||||
Waiting for SSH to be available...
|
||||
Detecting the provisioner...
|
||||
Started machines may have new IP addresses. You may need to re-run the `docker-machine env` command.
|
||||
|
||||
$ docker-machine start myvm2
|
||||
Starting "myvm2"...
|
||||
(myvm2) Check network to re-create if needed...
|
||||
(myvm2) Waiting for an IP...
|
||||
Machine "myvm2" was started.
|
||||
Waiting for SSH to be available...
|
||||
Detecting the provisioner...
|
||||
Started machines may have new IP addresses. You may need to re-run the `docker-machine env` command.
|
||||
```
|
||||
|
||||
[On to Part 5 >>](part5.md){: class="button outline-btn"}
|
||||
|
||||
## Recap and cheat sheet (optional)
|
||||
|
|
|
@ -90,25 +90,178 @@ Started Referral', 'Cloud', 'BYOH');"}, this provider does not support swarm
|
|||
mode. You can [register your own existing
|
||||
swarms](/docker-cloud/cloud-swarm/register-swarms/) with Docker Cloud.
|
||||
|
||||
### Deploy your app
|
||||
### Deploy your app on a cloud provider
|
||||
|
||||
[Connect to your swarm via Docker
|
||||
Cloud](/docker-cloud/cloud-swarm/connect-to-swarm.md). On Docker for
|
||||
Mac or Docker for Windows (Edge releases), you can [connect to your swarms
|
||||
directly through the desktop app
|
||||
menus](/docker-cloud/cloud-swarm/connect-to-swarm.md#use-docker-for-mac-or-windows-edge-to-connect-to-swarms).
|
||||
1. [Connect to your swarm via Docker
|
||||
Cloud](/docker-cloud/cloud-swarm/connect-to-swarm.md). There are a couple of different ways to connect:
|
||||
|
||||
Either way, this opens a terminal whose context is your local machine, but whose
|
||||
Docker commands are routed up to the swarm running on your cloud service
|
||||
provider. This is the same shell configuration method you've already learned
|
||||
with `docker-machine env`. You directly access both your local file system and
|
||||
your remote swarm, enabling pure `docker` commands:
|
||||
* From the Docker Cloud web interface in Swarm mode, select Swarms at
|
||||
the top of the page, click the swarm you want to connect to, and copy-paste the given command into a command line terminal.
|
||||
|
||||
```shell
|
||||
docker stack deploy -c docker-compose.yml getstartedlab
|
||||
```
|
||||

|
||||
|
||||
That's it! Your app is running in production and is managed by Docker Cloud.
|
||||
Or ...
|
||||
|
||||
* On Docker for Mac or Docker for Windows, you can [connect to your swarms directly through the desktop app menus](/docker-cloud/cloud-swarm/connect-to-swarm.md#use-docker-for-mac-or-windows-edge-to-connect-to-swarms).
|
||||
|
||||

|
||||
|
||||
Either way, this opens a terminal whose context is your local machine,
|
||||
but whose Docker commands are routed up to the swarm running on your
|
||||
cloud service provider. You directly access both your local file system
|
||||
and your remote swarm, enabling pure `docker` commands.
|
||||
|
||||
2. Run `docker stack deploy -c docker-compose.yml getstartedlab` to deploy
|
||||
the app on the cloud hosted swarm.
|
||||
|
||||
```shell
|
||||
docker stack deploy -c docker-compose.yml getstartedlab
|
||||
|
||||
Creating network getstartedlab_webnet
|
||||
Creating service getstartedlab_web
|
||||
Creating service getstartedlab_visualizer
|
||||
Creating service getstartedlab_redis
|
||||
```
|
||||
|
||||
Your app is now running on your cloud provider.
|
||||
|
||||
#### Run some swarm commands to verify the deployment
|
||||
|
||||
You can use the swarm command line, as you've done already, to browse and manage
|
||||
the swarm. Here are some examples that should look familiar by now:
|
||||
|
||||
* Use `docker node ls` to list the nodes.
|
||||
|
||||
```shell
|
||||
[getstartedlab] ~ $ docker node ls
|
||||
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
|
||||
9442yi1zie2l34lj01frj3lsn ip-172-31-5-208.us-west-1.compute.internal Ready Active
|
||||
jr02vg153pfx6jr0j66624e8a ip-172-31-6-237.us-west-1.compute.internal Ready Active
|
||||
thpgwmoz3qefdvfzp7d9wzfvi ip-172-31-18-121.us-west-1.compute.internal Ready Active
|
||||
n2bsny0r2b8fey6013kwnom3m * ip-172-31-20-217.us-west-1.compute.internal Ready Active Leader
|
||||
```
|
||||
|
||||
* Use `docker service ls` to list services.
|
||||
|
||||
```shell
|
||||
[getstartedlab] ~/sandbox/getstart $ docker service ls
|
||||
ID NAME MODE REPLICAS IMAGE PORTS
|
||||
x3jyx6uukog9 dockercloud-server-proxy global 1/1 dockercloud/server-proxy *:2376->2376/tcp
|
||||
ioipby1vcxzm getstartedlab_redis replicated 0/1 redis:latest *:6379->6379/tcp
|
||||
u5cxv7ppv5o0 getstartedlab_visualizer replicated 0/1 dockersamples/visualizer:stable *:8080->8080/tcp
|
||||
vy7n2piyqrtr getstartedlab_web replicated 5/5 sam/getstarted:part6 *:80->80/tcp
|
||||
```
|
||||
|
||||
* Use `docker service ps <service>` to view tasks for a service.
|
||||
|
||||
```shell
|
||||
[getstartedlab] ~/sandbox/getstart $ docker service ps vy7n2piyqrtr
|
||||
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
|
||||
qrcd4a9lvjel getstartedlab_web.1 sam/getstarted:part6 ip-172-31-5-208.us-west-1.compute.internal Running Running 20 seconds ago
|
||||
sknya8t4m51u getstartedlab_web.2 sam/getstarted:part6 ip-172-31-6-237.us-west-1.compute.internal Running Running 17 seconds ago
|
||||
ia730lfnrslg getstartedlab_web.3 sam/getstarted:part6 ip-172-31-20-217.us-west-1.compute.internal Running Running 21 seconds ago
|
||||
1edaa97h9u4k getstartedlab_web.4 sam/getstarted:part6 ip-172-31-18-121.us-west-1.compute.internal Running Running 21 seconds ago
|
||||
uh64ez6ahuew getstartedlab_web.5 sam/getstarted:part6 ip-172-31-18-121.us-west-1.compute.internal Running Running 22 seconds ago
|
||||
```
|
||||
|
||||
#### Open ports to services on cloud provider machines
|
||||
|
||||
At this point, your app is deployed as a swarm on your cloud provider servers,
|
||||
as evidenced by the `docker` commands you just ran. But, you still need to
|
||||
open ports on your cloud servers in order to:
|
||||
|
||||
* allow communication between the `redis` service and `web` service on
|
||||
the worker nodes
|
||||
|
||||
* allow inbound traffic to the `web` service on the worker nodes so that
|
||||
Hello World and Visualizer are accessible from a web browser.
|
||||
|
||||
* allow inbound SSH traffic on the server that is running the `manager` (this may be already set on your cloud provider)
|
||||
|
||||
{: id="table-of-ports"}
|
||||
|
||||
These are the ports you need to expose for each service:
|
||||
|
||||
| Service | Type | Protocol | Port |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| `web` | HTTP | TCP | 80 |
|
||||
| `visualizer` | HTTP | TCP | 8080 |
|
||||
| `redis` | TCP | TCP | 6379 |
|
||||
|
||||
Methods for doing this will vary depending on your cloud provider.
|
||||
|
||||
We'll use Amazon Web Services (AWS) as an example.
|
||||
|
||||
> What about the redis service to persist data?
|
||||
>
|
||||
> To get the `redis` service working, you need to `ssh` into
|
||||
the cloud server where the `manager` is running, and make a `data/`
|
||||
directory in `/home/docker/` before you run `docker stack deploy`.
|
||||
Another option is to change the data path in the `docker-stack.yml` to
|
||||
a pre-existing path on the `manager` server. This example does not
|
||||
include this step, so the `redis` service is not up in the example output.
|
||||
|
||||
#### Example: AWS
|
||||
|
||||
1. Log in to the [AWS Console](https://aws.amazon.com/){: target="_blank"
|
||||
class="_"}, go to the EC2 Dashboard, and click into your **Running Instances**
|
||||
to view the nodes.
|
||||
|
||||
2. On the left menu, go to Network & Security > **Security Groups**.
|
||||
|
||||
You'll see security groups related to your swarm
|
||||
for `getstartedlab-Manager-<xxx>`, `getstartedlab-Nodes-<xxx>`,
|
||||
and `getstartedlab-SwarmWide-<xxx>`.
|
||||
|
||||
3. Select the "Node" security group for the swarm. The group name
|
||||
will be something like this: `getstartedlab-NodeVpcSG-9HV9SMHDZT8C`.
|
||||
|
||||
4. Add Inbound rules for the `web`, `visualizer`, and `redis`
|
||||
services, setting the Type, Protocol and Port for each as shown in the
|
||||
[table above](#table-of-ports), and click **Save** to apply the rules.
|
||||
|
||||

|
||||
|
||||
> **Tip**: When you save the new rules, HTTP and TCP
|
||||
ports will be auto-created for both IPv4 and IPv6 style addresses.
|
||||
|
||||

|
||||
|
||||
5. Go to the list of **Running Instances**, get the public DNS name for
|
||||
one of the workers, and paste it into the address bar of your web browser.
|
||||
|
||||

|
||||
|
||||
Just as in the previous parts of the tutorial, the Hello World app
|
||||
displays on port `80`, and the Visualizer displays on port `8080`.
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
### Iteration and cleanup
|
||||
|
||||
From here you can do everything you learned about in previous parts of the
|
||||
tutorial.
|
||||
|
||||
* Scale the app by changing the `docker-compose.yml` file and redeploy
|
||||
on-the-fly with the `docker stack deploy` command.
|
||||
|
||||
* Change the app behavior by editing code, then rebuild, and push the new image.
|
||||
(To do this, follow the same steps you took earlier to [build the
|
||||
app](part2.md#build-the-app) and [publish the
|
||||
image](part2.md#publish-the-image)).
|
||||
|
||||
* You can tear down the stack with `docker stack rm`. For example:
|
||||
|
||||
```
|
||||
docker stack rm getstartedlab
|
||||
```
|
||||
|
||||
Unlike the scenario where you were running the swarm on local Docker machine
|
||||
VMs, your swarm and any apps deployed on it will continue to run on cloud
|
||||
servers regardless of whether you shut down your local host.
|
||||
|
||||
{% endcapture %}
|
||||
{% capture enterpriseboilerplate %}
|
||||
Customers of Docker Enterprise Edition run a stable, commercially-supported
|
||||
|
|