tier 1 updates for freshness (#18686)
Signed-off-by: Craig Osterhout <craig.osterhout@docker.com>
After Width: | Height: | Size: 8.1 KiB |
|
@ -57,17 +57,17 @@ keep image size small:
|
|||
|
||||
- When building images, always tag them with useful tags which codify version
|
||||
information, intended destination (`prod` or `test`, for instance), stability,
|
||||
or other information that is useful when deploying the application in
|
||||
different environments. Do not rely on the automatically-created `latest` tag.
|
||||
or other information that's useful when deploying the application in
|
||||
different environments. Don't rely on the automatically-created `latest` tag.
|
||||
|
||||
## Where and how to persist application data
|
||||
|
||||
- **Avoid** storing application data in your container's writable layer using
|
||||
- Avoid storing application data in your container's writable layer using
|
||||
[storage drivers](../storage/storagedriver/select-storage-driver.md). This increases the
|
||||
size of your container and is less efficient from an I/O perspective than
|
||||
using volumes or bind mounts.
|
||||
- Instead, store data using [volumes](../storage/volumes.md).
|
||||
- One case where it is appropriate to use
|
||||
- One case where it's appropriate to use
|
||||
[bind mounts](../storage/bind-mounts.md) is during development,
|
||||
when you may want to mount your source directory or a binary you just built
|
||||
into your container. For production, use a volume instead, mounting it into
|
||||
|
@ -88,7 +88,7 @@ keep image size small:
|
|||
|
||||
- Take this even further by requiring your development, testing, and
|
||||
security teams to [sign images](../engine/reference/commandline/trust.md)
|
||||
before they are deployed into production. This way, before an image is
|
||||
before the teams deploy the images into production. This way, before an image is
|
||||
deployed into production, it has been tested and signed off by, for instance,
|
||||
development, quality, and security teams.
|
||||
|
||||
|
|
|
@ -228,7 +228,7 @@ so on.
|
|||
For external access, your users can execute `docker run` with a flag indicating
|
||||
how to map the specified port to the port of their choice.
|
||||
For container linking, Docker provides environment variables for the path from
|
||||
the recipient container back to the source (ie, `MYSQL_PORT_3306_TCP`).
|
||||
the recipient container back to the source (for example, `MYSQL_PORT_3306_TCP`).
|
||||
|
||||
For more information about `EXPOSE`, see [Dockerfile reference for the EXPOSE instruction](../../engine/reference/builder.md#expose).
|
||||
|
||||
|
@ -240,7 +240,7 @@ example, `ENV PATH=/usr/local/nginx/bin:$PATH` ensures that `CMD ["nginx"]`
|
|||
just works.
|
||||
|
||||
The `ENV` instruction is also useful for providing the required environment
|
||||
variables specific to services you wish to containerize, such as Postgres’s
|
||||
variables specific to services you want to containerize, such as Postgres’s
|
||||
`PGDATA`.
|
||||
|
||||
Lastly, `ENV` can also be used to set commonly used version numbers so that
|
||||
|
@ -427,7 +427,7 @@ ENTRYPOINT ["/docker-entrypoint.sh"]
|
|||
CMD ["postgres"]
|
||||
```
|
||||
|
||||
This script allows the user to interact with Postgres in several ways.
|
||||
This script lets you interact with Postgres in several ways.
|
||||
|
||||
It can simply start Postgres:
|
||||
|
||||
|
@ -435,13 +435,13 @@ It can simply start Postgres:
|
|||
$ docker run postgres
|
||||
```
|
||||
|
||||
Or, it can be used to run Postgres and pass parameters to the server:
|
||||
Or, you can use it to run Postgres and pass parameters to the server:
|
||||
|
||||
```console
|
||||
$ docker run postgres postgres --help
|
||||
```
|
||||
|
||||
Lastly, it could also be used to start a totally different tool, such as Bash:
|
||||
Lastly, you can use it to start a totally different tool, such as Bash:
|
||||
|
||||
```console
|
||||
$ docker run --rm -it postgres bash
|
||||
|
@ -451,7 +451,7 @@ For more information about `ENTRYPOINT`, see [Dockerfile reference for the ENTRY
|
|||
|
||||
### VOLUME
|
||||
|
||||
The `VOLUME` instruction should be used to expose any database storage area,
|
||||
YOu should use the `VOLUME` instruction to expose any database storage area,
|
||||
configuration storage, or files and folders created by your Docker container. You
|
||||
are strongly encouraged to use `VOLUME` for any combination of mutable or user-serviceable
|
||||
parts of your image.
|
||||
|
|
Before Width: | Height: | Size: 132 KiB |
After Width: | Height: | Size: 33 KiB |
Before Width: | Height: | Size: 175 KiB |
|
@ -12,7 +12,7 @@ container. This includes:
|
|||
1. [Choosing the right base image](#choose-the-right-base-image) from a trusted source and keeping it small
|
||||
2. [Using multi-stage builds](#use-multi-stage-builds)
|
||||
3. [Rebuilding images](#rebuild-images)
|
||||
4. [Check your image for vulnerabilities](#check-your-image-for-vulnerabilities)
|
||||
4. [Checking your image for vulnerabilities](#check-your-image-for-vulnerabilities)
|
||||
|
||||
### Choose the right base image
|
||||
|
||||
|
@ -30,7 +30,7 @@ Docker verifying the authenticity of the content in their repositories. When you
|
|||
pick your base image, look out for the **Official Image** and **Verified Publisher**
|
||||
badges.
|
||||
|
||||

|
||||

|
||||
|
||||
When building your own image from a Dockerfile, ensure you choose a minimal base
|
||||
image that matches your requirements. A smaller base image not only offers
|
||||
|
@ -58,7 +58,7 @@ image. This can result in a concise final image.
|
|||
This method of creating a tiny image doesn't only significantly reduce
|
||||
complexity, but also reduces the chance of implementing vulnerable artifacts in your
|
||||
image. Therefore, instead of images that are built on images, that again are
|
||||
built on other images, multi-stage builds allow you to 'cherry pick' your
|
||||
built on other images, multi-stage builds let you 'cherry pick' your
|
||||
artifacts without inheriting the vulnerabilities from the base images on which
|
||||
they rely.
|
||||
|
||||
|
@ -68,7 +68,7 @@ For detailed information on how to configure multi-stage builds, see
|
|||
### Rebuild images
|
||||
|
||||
A Docker image is built from a Dockerfile. A Dockerfile contains a set of
|
||||
instructions which allows you to automate the steps you would normally
|
||||
instructions which lets you automate the steps you would normally
|
||||
(manually) take to create an image. Additionally, it can include some imported
|
||||
libraries and install custom software. These appear as instructions in the
|
||||
Dockerfile.
|
||||
|
@ -86,7 +86,7 @@ FROM ubuntu:latest
|
|||
RUN apt-get -y update && apt-get install -y python
|
||||
```
|
||||
|
||||
We recommend that you rebuild your Docker image regularly to prevent known
|
||||
Docker recommends that you rebuild your Docker image regularly to prevent known
|
||||
vulnerabilities that have been addressed. When rebuilding, use the option
|
||||
`--no-cache` to avoid cache hits and to ensure a fresh download.
|
||||
|
||||
|
|
|
@ -14,14 +14,14 @@ Docker Hub limits the number of Docker image downloads, or pulls, based on the a
|
|||
| [Authenticated users](#how-do-i-authenticate-pull-requests)| 200 pulls per 6 hour period |
|
||||
| Users with a paid [Docker subscription](https://www.docker.com/pricing) | Up to 5000 pulls per day |
|
||||
|
||||
If you require a higher number of pulls, you can also purchase an [Enhanced Service Account add-on](service-accounts.md#enhanced-service-account-add-on-pricing).
|
||||
If you require a higher number of pulls, you can also buy an [Enhanced Service Account add-on](service-accounts.md#enhanced-service-account-add-on-pricing).
|
||||
|
||||
|
||||
## Definition of limits
|
||||
|
||||
A user's limit is equal to the highest entitlement of their
|
||||
personal account or any organization they belong to. To take
|
||||
advantage of this, you must log in to
|
||||
advantage of this, you must sign in to
|
||||
[Docker Hub](https://hub.docker.com/)
|
||||
as an authenticated user. For more information, see
|
||||
[How do I authenticate pull requests](#how-do-i-authenticate-pull-requests).
|
||||
|
@ -89,7 +89,7 @@ ratelimit-remaining: 76;w=21600
|
|||
docker-ratelimit-source: 192.0.2.1
|
||||
```
|
||||
|
||||
In the example above, the pull limit is 100 pulls per 21600 seconds (6 hours), and there are 76 pulls remaining.
|
||||
In the previous example, the pull limit is 100 pulls per 21600 seconds (6 hours), and there are 76 pulls remaining.
|
||||
|
||||
### I don't see any RateLimit headers
|
||||
|
||||
|
|
|
@ -61,7 +61,7 @@ Once you have created a repository, you can start using `docker push` to push
|
|||
images.
|
||||
|
||||
To push an image to Docker Hub, you must first name your local image using your
|
||||
Docker Hub username and the repository name that you created.
|
||||
Docker ID and the repository name that you created.
|
||||
|
||||
If you want to add multiple images to a repository, add a specific `:<tag>` to them, for example `docs/base:testing`. If it's not specified, the tag defaults to `latest`.
|
||||
|
||||
|
|
|
@ -82,10 +82,10 @@ Optionally, you can sign in to an existing Docker account with your Google or Gi
|
|||
|
||||
If you try to sign in with your social provider and don't have a Docker account yet, a new account will be created for you. Follow the on-screen instructions to create a Docker ID using your social provider.
|
||||
|
||||
## Reset your password at sign in
|
||||
|
||||
To reset your password, enter your email address on the [Sign in](https://login.docker.com/u/login) page and continue to sign in. When prompted for your password, select **Forgot password?**.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
If you run into trouble with your Docker ID account, know that we're here to help! If you want to retrieve or reset your password, [enter your email address](https://login.docker.com/u/login) for additional instructions.
|
||||
|
||||
You can use the [Docker forums](https://forums.docker.com/) to ask questions amongst other Docker community members, while our [hub-feedback GitHub repository](https://github.com/docker/hub-feedback) allows you to provide feedback on how we can better improve the experience with Docker Hub.
|
||||
|
||||
If you still need any help, [create a support ticket](https://hub.docker.com/support/contact/) and let us know how we can help you.
|
||||
For support and troubleshooting information, see [Get support](../support.md).
|
|
@ -137,7 +137,7 @@ Now that you have an image, you can run the application in a container using the
|
|||
2. After a few seconds, open your web browser to [http://localhost:3000](http://localhost:3000).
|
||||
You should see your app.
|
||||
|
||||

|
||||

|
||||
|
||||
|
||||
3. Add an item or two and see that it works as you expect. You can mark items as complete and remove them. Your frontend is successfully storing items in the backend.
|
||||
|
@ -166,7 +166,7 @@ df784548666d getting-started "docker-entrypoint.s…" 2 minutes ago
|
|||
|
||||
In Docker Desktop, select the **Containers** tab to see a list of your containers.
|
||||
|
||||

|
||||

|
||||
|
||||
{{< /tab >}}
|
||||
{{< /tabs >}}
|
||||
|
|
|
@ -29,7 +29,7 @@ To push an image, you first need to create a repository on Docker Hub.
|
|||
|
||||
In the following image, you can see an example Docker command from Docker Hub. This command will push to this repository.
|
||||
|
||||

|
||||

|
||||
|
||||
|
||||
## Push the image
|
||||
|
@ -89,7 +89,7 @@ new instance that has never seen this container image. To do this, you will use
|
|||
|
||||
4. Select the **ADD NEW INSTANCE** option on the left side bar. If you don't see it, make your browser a little wider. After a few seconds, a terminal window opens in your browser.
|
||||
|
||||

|
||||

|
||||
|
||||
5. In the terminal, start your freshly pushed app.
|
||||
|
||||
|
|
|
@ -163,7 +163,7 @@ To start the todo app container with the volume mounted:
|
|||
|
||||
1. Once the container starts up, open the app and add a few items to your todo list.
|
||||
|
||||

|
||||

|
||||
|
||||
|
||||
2. Stop and remove the container for the todo app. Use Docker Desktop or `docker ps` to get the ID and then `docker rm -f <id>` to remove it.
|
||||
|
|
|
@ -320,7 +320,7 @@ Update your app on your host machine and see the changes reflected in the contai
|
|||
restarts the server. It might take a few seconds for the Node server to
|
||||
restart. If you get an error, try refreshing after a few seconds.
|
||||
|
||||

|
||||

|
||||
|
||||
3. Feel free to make any other changes you'd like to make. Each time you make a
|
||||
change and save a file, the change is reflected in the container because of
|
||||
|
|
|
@ -17,7 +17,7 @@ container or run it separately?" In general, each container should do one thing
|
|||
|
||||
And there are more reasons. So, like the following diagram, it's best to run your app in multiple containers.
|
||||
|
||||

|
||||

|
||||
|
||||
|
||||
## Container networking
|
||||
|
|
Before Width: | Height: | Size: 65 KiB |
After Width: | Height: | Size: 26 KiB |
Before Width: | Height: | Size: 175 KiB |
After Width: | Height: | Size: 40 KiB |
Before Width: | Height: | Size: 62 KiB |
After Width: | Height: | Size: 9.1 KiB |
Before Width: | Height: | Size: 41 KiB |
After Width: | Height: | Size: 9.5 KiB |
Before Width: | Height: | Size: 39 KiB |
After Width: | Height: | Size: 11 KiB |
Before Width: | Height: | Size: 167 KiB |
After Width: | Height: | Size: 81 KiB |
Before Width: | Height: | Size: 23 KiB |
After Width: | Height: | Size: 4.8 KiB |
Before Width: | Height: | Size: 69 KiB |
Before Width: | Height: | Size: 25 KiB |
Before Width: | Height: | Size: 21 KiB |
After Width: | Height: | Size: 4.4 KiB |
Before Width: | Height: | Size: 650 KiB |
|
@ -13,15 +13,15 @@ description: Learn how to describe and deploy a simple application on Kubernetes
|
|||
|
||||
## Introduction
|
||||
|
||||
Now that we've demonstrated that the individual components of our application run as stand-alone containers, it's time to arrange for them to be managed by an orchestrator like Kubernetes. Kubernetes provides many tools for scaling, networking, securing and maintaining your containerized applications, above and beyond the abilities of containers themselves.
|
||||
Now that you've demonstrated that the individual components of your application run as stand-alone containers, it's time to arrange for them to be managed by an orchestrator like Kubernetes. Kubernetes provides many tools for scaling, networking, securing and maintaining your containerized applications, above and beyond the abilities of containers themselves.
|
||||
|
||||
In order to validate that our containerized application works well on Kubernetes, we'll use Docker Desktop's built in Kubernetes environment right on our development machine to deploy our application, before handing it off to run on a full Kubernetes cluster in production. The Kubernetes environment created by Docker Desktop is _fully featured_, meaning it has all the Kubernetes features your app will enjoy on a real cluster, accessible from the convenience of your development machine.
|
||||
In order to validate that your containerized application works well on Kubernetes, you'll use Docker Desktop's built in Kubernetes environment right on your development machine to deploy your application, before handing it off to run on a full Kubernetes cluster in production. The Kubernetes environment created by Docker Desktop is _fully featured_, meaning it has all the Kubernetes features your app will enjoy on a real cluster, accessible from the convenience of your development machine.
|
||||
|
||||
## Describing apps using Kubernetes YAML
|
||||
|
||||
All containers in Kubernetes are scheduled as pods, which are groups of co-located containers that share some resources. Furthermore, in a realistic application we almost never create individual pods. Instead, most of our workloads are scheduled as deployments, which are scalable groups of pods maintained automatically by Kubernetes. Lastly, all Kubernetes objects can and should be described in manifests called Kubernetes YAML files. These YAML files describe all the components and configurations of your Kubernetes app, and can be used to easily create and destroy your app in any Kubernetes environment.
|
||||
All containers in Kubernetes are scheduled as pods, which are groups of co-located containers that share some resources. Furthermore, in a realistic application you almost never create individual pods. Instead, most of your workloads are scheduled as deployments, which are scalable groups of pods maintained automatically by Kubernetes. Lastly, all Kubernetes objects can and should be described in manifests called Kubernetes YAML files. These YAML files describe all the components and configurations of your Kubernetes app, and can be used to create and destroy your app in any Kubernetes environment.
|
||||
|
||||
You already wrote a very basic Kubernetes YAML file in the Orchestration overview part of this tutorial. Now, let's write a slightly more sophisticated YAML file to run and manage our Todo app, the container `getting-started` image created in [Part 2](02_our_app.md) of the Quickstart tutorial. Place the following in a file called `bb.yaml`:
|
||||
You already wrote a basic Kubernetes YAML file in the Orchestration overview part of this tutorial. Now, you can write a slightly more sophisticated YAML file to run and manage your Todo app, the container `getting-started` image created in [Part 2](02_our_app.md) of the Quickstart tutorial. Place the following in a file called `bb.yaml`:
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
|
@ -59,7 +59,7 @@ spec:
|
|||
nodePort: 30001
|
||||
```
|
||||
|
||||
In this Kubernetes YAML file, we have two objects, separated by the `---`:
|
||||
In this Kubernetes YAML file, there are two objects, separated by the `---`:
|
||||
- A `Deployment`, describing a scalable group of identical pods. In this case, you'll get just one `replica`, or copy of your pod, and that pod (which is described under the `template:` key) has just one container in it, based off of your `getting-started` image from the previous step in this tutorial.
|
||||
- A `NodePort` service, which will route traffic from port 30001 on your host to port 3000 inside the pods it routes to, allowing you to reach your Todo app from the network.
|
||||
|
||||
|
@ -109,7 +109,7 @@ In this Kubernetes YAML file, we have two objects, separated by the `---`:
|
|||
|
||||
In addition to the default `kubernetes` service, we see our `bb-entrypoint` service, accepting traffic on port 30001/TCP.
|
||||
|
||||
3. Open a browser and visit your Todo app at `localhost:30001`. You should see your Todo application, the same as when we ran it as a stand-alone container in [Part 2](02_our_app.md) of the Quickstart tutorial.
|
||||
3. Open a browser and visit your Todo app at `localhost:30001`. You should see your Todo application, the same as when you ran it as a stand-alone container in [Part 2](02_our_app.md) of the tutorial.
|
||||
|
||||
4. Once satisfied, tear down your application:
|
||||
|
||||
|
@ -119,9 +119,9 @@ In this Kubernetes YAML file, we have two objects, separated by the `---`:
|
|||
|
||||
## Conclusion
|
||||
|
||||
At this point, we have successfully used Docker Desktop to deploy our application to a fully-featured Kubernetes environment on our development machine. You can now add other components to your app and taking advantage of all the features and power of Kubernetes, right on your own machine.
|
||||
At this point, you have successfully used Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine. You can now add other components to your app and taking advantage of all the features and power of Kubernetes, right on your own machine.
|
||||
|
||||
In addition to deploying to Kubernetes, we have also described our application as a Kubernetes YAML file. This simple text file contains everything we need to create our application in a running state. We can check it into version control and share it with our colleagues, allowing us to distribute our applications to other clusters (like the testing and production clusters that probably come after our development environments) easily.
|
||||
In addition to deploying to Kubernetes, you have also described your application as a Kubernetes YAML file. This simple text file contains everything you need to create your application in a running state. You can check it in to version control and share it with your colleagues. This let you distribute your applications to other clusters (like the testing and production clusters that probably come after your development environments).
|
||||
|
||||
## Kubernetes references
|
||||
|
||||
|
|
|
@ -6,8 +6,8 @@ description: Get oriented on some basics of Docker and install Docker Desktop.
|
|||
|
||||
Containerization provides an opportunity to move and scale applications to
|
||||
clouds and data centers. Containers effectively guarantee that those applications run the
|
||||
same way anywhere, allowing us to quickly and easily take advantage of all
|
||||
these environments. Additionally, as we scale our applications up, we need some
|
||||
same way anywhere, allowing you to quickly and easily take advantage of all
|
||||
these environments. Additionally, as you scale your applications up, you need some
|
||||
tooling to help automate the maintenance of those applications, enable the
|
||||
replacement of failed containers automatically, and manage the roll-out of
|
||||
updates and reconfigurations of those containers during their lifecycle.
|
||||
|
|
|
@ -87,7 +87,7 @@ daemon. The Docker client and daemon communicate using a REST API, over UNIX
|
|||
sockets or a network interface. Another Docker client is Docker Compose,
|
||||
that lets you work with applications consisting of a set of containers.
|
||||
|
||||

|
||||

|
||||
|
||||
### The Docker daemon
|
||||
|
||||
|
|
|
@ -9,11 +9,11 @@ Docker and the broader community of Docker experts have put together many differ
|
|||
|
||||
## Hosted labs
|
||||
|
||||
These self-paced and hands-on workshops use a free, hosted environment ([Play with Kubernetes](https://labs.play-with-k8s.com/)) that does not require any installation. Follow along and learn more about Kubernetes.
|
||||
These self-paced and hands-on workshops use a free, hosted environment ([Play with Kubernetes](https://labs.play-with-k8s.com/)) that doesn't require any installation. Follow along and learn more about Kubernetes.
|
||||
|
||||
* [Kubernetes Workshop](https://training.play-with-kubernetes.com/kubernetes-workshop/)
|
||||
|
||||
* Labs are free but require registration with a Docker ID.
|
||||
\* Labs are free but require registration with a Docker ID.
|
||||
|
||||
## Self-guided tutorials
|
||||
|
||||
|
|
|
@ -18,15 +18,15 @@ aliases:
|
|||
|
||||
## Introduction
|
||||
|
||||
Now that we've demonstrated that the individual components of our application run as stand-alone containers and shown how to deploy it using Kubernetes, let's look at how to arrange for them to be managed by Docker Swarm. Swarm provides many tools for scaling, networking, securing and maintaining your containerized applications, above and beyond the abilities of containers themselves.
|
||||
Now that you've demonstrated that the individual components of your application run as stand-alone containers and shown how to deploy it using Kubernetes, you can look at how to arrange for them to be managed by Docker Swarm. Swarm provides many tools for scaling, networking, securing and maintaining your containerized applications, above and beyond the abilities of containers themselves.
|
||||
|
||||
In order to validate that our containerized application works well on Swarm, we'll use Docker Desktop's built in Swarm environment right on our development machine to deploy our application, before handing it off to run on a full Swarm cluster in production. The Swarm environment created by Docker Desktop is fully featured, meaning it has all the Swarm features your app will enjoy on a real cluster, accessible from the convenience of your development machine.
|
||||
In order to validate that your containerized application works well on Swarm, you'll use Docker Desktop's built in Swarm environment right on your development machine to deploy your application, before handing it off to run on a full Swarm cluster in production. The Swarm environment created by Docker Desktop is fully featured, meaning it has all the Swarm features your app will enjoy on a real cluster, accessible from the convenience of your development machine.
|
||||
|
||||
## Describe apps using stack files
|
||||
|
||||
Swarm never creates individual containers like we did in the previous step of this tutorial. Instead, all Swarm workloads are scheduled as services, which are scalable groups of containers with added networking features maintained automatically by Swarm. Furthermore, all Swarm objects can and should be described in manifests called stack files. These YAML files describe all the components and configurations of your Swarm app, and can be used to easily create and destroy your app in any Swarm environment.
|
||||
Swarm never creates individual containers like you did in the previous step of this tutorial. Instead, all Swarm workloads are scheduled as services, which are scalable groups of containers with added networking features maintained automatically by Swarm. Furthermore, all Swarm objects can and should be described in manifests called stack files. These YAML files describe all the components and configurations of your Swarm app, and can be used to create and destroy your app in any Swarm environment.
|
||||
|
||||
Let's write a simple stack file to run and manage our Todo app, the container `getting-started` image created in [Part 2](02_our_app.md) of the Quickstart tutorial. Place the following in a file called `bb-stack.yaml`:
|
||||
Now you can write a simple stack file to run and manage your Todo app, the container `getting-started` image created in [Part 2](02_our_app.md) of the tutorial. Place the following in a file called `bb-stack.yaml`:
|
||||
|
||||
{{< include "swarm-compose-compat.md" >}}
|
||||
|
||||
|
@ -40,7 +40,7 @@ services:
|
|||
- "8000:3000"
|
||||
```
|
||||
|
||||
In this Swarm YAML file, we have just one object, a `service`, describing a scalable group of identical containers. In this case, you'll get just one container (the default), and that container will be based on your `getting-started` image created in [Part 2](02_our_app.md) of the Quickstart tutorial. In addition, We've asked Swarm to forward all traffic arriving at port 8000 on our development machine to port 3000 inside our getting-started container.
|
||||
In this Swarm YAML file, there is one object, a `service`, describing a scalable group of identical containers. In this case, you'll get just one container (the default), and that container will be based on your `getting-started` image created in [Part 2](02_our_app.md) of the tutorial. In addition, you've asked Swarm to forward all traffic arriving at port 8000 on your development machine to port 3000 inside our getting-started container.
|
||||
|
||||
> **Kubernetes Services and Swarm Services are very different**
|
||||
>
|
||||
|
@ -82,9 +82,9 @@ In this Swarm YAML file, we have just one object, a `service`, describing a scal
|
|||
il7elwunymbs demo_bb-app replicated 1/1 getting-started:latest *:8000->3000/tcp
|
||||
```
|
||||
|
||||
This indicates 1/1 containers you asked for as part of your services are up and running. Also, we see that port 8000 on your development machine is getting forwarded to port 3000 in your getting-started container.
|
||||
This indicates 1/1 containers you asked for as part of your services are up and running. Also, you see that port 8000 on your development machine is getting forwarded to port 3000 in your getting-started container.
|
||||
|
||||
3. Open a browser and visit your Todo app at `localhost:8000`; you should see your Todo application, the same as when we ran it as a stand-alone container in [Part 2](02_our_app.md) of the Quickstart tutorial.
|
||||
3. Open a browser and visit your Todo app at `localhost:8000`; you should see your Todo application, the same as when you ran it as a stand-alone container in [Part 2](02_our_app.md) of the tutorial.
|
||||
|
||||
4. Once satisfied, tear down your application:
|
||||
|
||||
|
@ -94,9 +94,9 @@ In this Swarm YAML file, we have just one object, a `service`, describing a scal
|
|||
|
||||
## Conclusion
|
||||
|
||||
At this point, we have successfully used Docker Desktop to deploy our application to a fully-featured Swarm environment on our development machine. You can now add other components to your app and taking advantage of all the features and power of Swarm, right on your own machine.
|
||||
At this point, you've successfully used Docker Desktop to deploy your application to a fully-featured Swarm environment on your development machine. You can now add other components to your app and taking advantage of all the features and power of Swarm, right on your own machine.
|
||||
|
||||
In addition to deploying to Swarm, we have also described our application as a stack file. This simple text file contains everything we need to create our application in a running state; we can check it into version control and share it with our colleagues, allowing us to distribute our applications to other clusters (like the testing and production clusters that probably come after our development environments) easily.
|
||||
In addition to deploying to Swarm, you've also described your application as a stack file. This simple text file contains everything you need to create your application in a running state; you can check it in to version control and share it with your colleagues, letting you to distribute your applications to other clusters (like the testing and production clusters that probably come after your development environments).
|
||||
|
||||
## Swarm and CLI references
|
||||
|
||||
|
|
|
@ -25,21 +25,21 @@ Learn how to containerize your applications and start developing using Docker. C
|
|||
|
||||
<div class="grid grid-cols-3 auto-rows-fr sm:flex-col sm:h-auto gap-4">
|
||||
<div class="flex items-center flex-1 shadow p-4">
|
||||
<a href="/language/nodejs/"><img class="m-auto rounded" src="/language/images/nodejs.png" alt="Develop with Node"></a>
|
||||
<a href="/language/nodejs/"><img class="m-auto rounded" src="/language/images/nodejs.webp" alt="Develop with Node"></a>
|
||||
</div>
|
||||
<div class="flex items-center flex-1 shadow p-4">
|
||||
<a href="/language/python/"><img class="m-auto rounded" src="/language/images/python.png" alt="Develop with Python"></a>
|
||||
<a href="/language/python/"><img class="m-auto rounded" src="/language/images/python.webp" alt="Develop with Python"></a>
|
||||
</div>
|
||||
<div class="flex items-center flex-1 shadow p-4">
|
||||
<a href="/language/java/"><img class="m-auto rounded" src="/language/images/java.png" alt="Develop with Java"></a>
|
||||
<a href="/language/java/"><img class="m-auto rounded" src="/language/images/java.webp" alt="Develop with Java"></a>
|
||||
</div>
|
||||
<div class="flex items-center flex-1 shadow p-4">
|
||||
<a href="/language/golang/"><img class="m-auto rounded" src="/language/images/golang.png" alt="Develop with Go"></a>
|
||||
<a href="/language/golang/"><img class="m-auto rounded" src="/language/images/golang.webp" alt="Develop with Go"></a>
|
||||
</div>
|
||||
<div class="flex items-center flex-1 shadow p-4">
|
||||
<a href="/language/dotnet/"><img class="m-auto rounded" src="/language/images/c-sharp.png" alt="Develop with C#"></a>
|
||||
<a href="/language/dotnet/"><img class="m-auto rounded" src="/language/images/c-sharp.webp" alt="Develop with C#"></a>
|
||||
</div>
|
||||
<div class="flex items-center flex-1 shadow p-4">
|
||||
<a href="/language/rust/"><img class="m-auto rounded" src="/language/images/rust-logo.png" alt="Develop with Rust"></a>
|
||||
<a href="/language/rust/"><img class="m-auto rounded" src="/language/images/rust-logo.webp" alt="Develop with Rust"></a>
|
||||
</div>
|
||||
</div>
|
|
@ -24,17 +24,17 @@ application](containerize.md).
|
|||
|
||||
To get the updated code, you need to checkout the `add-db` branch. For the changes you made in [Containerize a .NET application](containerize.md), for this section, you can stash them. In a terminal, run the following commands in the `docker-dotnet-sample` directory.
|
||||
|
||||
Stash any previous changes.
|
||||
1. Stash any previous changes.
|
||||
|
||||
```console
|
||||
$ git stash -u
|
||||
```
|
||||
```console
|
||||
$ git stash -u
|
||||
```
|
||||
|
||||
Check out the new branch with the updated application.
|
||||
2. Check out the new branch with the updated application.
|
||||
|
||||
```console
|
||||
$ git checkout add-db
|
||||
```
|
||||
```console
|
||||
$ git checkout add-db
|
||||
```
|
||||
|
||||
In the `add-db` branch, only the .NET application has been updated. None of the Docker assets have been updated yet.
|
||||
|
||||
|
|
|
@ -295,7 +295,7 @@ FROM golang:1.19
|
|||
|
||||
## Build the image
|
||||
|
||||
Now that you've created our `Dockerfile`, build an image from it. The `docker
|
||||
Now that you've created your `Dockerfile`, build an image from it. The `docker
|
||||
build` command creates Docker images from the `Dockerfile` and a context. A
|
||||
build context is the set of files located in the specified path or URL. The
|
||||
Docker build process can access any of the files located in the context.
|
||||
|
|
Before Width: | Height: | Size: 33 KiB |
Before Width: | Height: | Size: 47 KiB |
Before Width: | Height: | Size: 62 KiB |
Before Width: | Height: | Size: 116 KiB |
Before Width: | Height: | Size: 32 KiB |
After Width: | Height: | Size: 12 KiB |
Before Width: | Height: | Size: 15 KiB |
After Width: | Height: | Size: 16 KiB |
Before Width: | Height: | Size: 6.8 KiB |
After Width: | Height: | Size: 4.5 KiB |
Before Width: | Height: | Size: 12 KiB |
After Width: | Height: | Size: 5.5 KiB |
Before Width: | Height: | Size: 82 KiB |
After Width: | Height: | Size: 3.2 KiB |
Before Width: | Height: | Size: 22 KiB |
After Width: | Height: | Size: 8.5 KiB |
|
@ -171,7 +171,7 @@ $ docker compose -f docker-compose.dev.yml up --build
|
|||
|
||||
You pass the `--build` flag so Docker will compile your image and then starts the containers. You should see similar output if it runs successfully:
|
||||
|
||||

|
||||

|
||||
|
||||
Now, test your API endpoint. Run the following curl command:
|
||||
|
||||
|
@ -191,7 +191,7 @@ You should receive the following response:
|
|||
|
||||
You’ll use the debugger that comes with the IntelliJ IDEA. You can use the community version of this IDE. Open your project in IntelliJ IDEA, go to the **Run** menu, and then **Edit Configuration**. Add a new Remote JVM Debug configuration similar to the following:
|
||||
|
||||

|
||||

|
||||
|
||||
Set a breakpoint.
|
||||
|
||||
|
@ -199,11 +199,11 @@ Open `src/main/java/org/springframework/samples/petclinic/vet/VetController.java
|
|||
|
||||
To start your debug session, select the **Run** menu and then **Debug _NameOfYourConfiguration_**.
|
||||
|
||||

|
||||

|
||||
|
||||
You should now see the connection in the logs of your Compose application.
|
||||
|
||||

|
||||

|
||||
|
||||
You can now call the server endpoint.
|
||||
|
||||
|
@ -213,7 +213,7 @@ $ curl --request GET --url http://localhost:8080/vets
|
|||
|
||||
You should have seen the code break on the marked line and now you are able to use the debugger just like you would normally. You can also inspect and watch variables, set conditional breakpoints, view stack traces and a do bunch of other stuff.
|
||||
|
||||

|
||||

|
||||
|
||||
You can also activate the live reload option provided by SpringBoot Dev Tools. Check out the [SpringBoot documentation](https://docs.spring.io/spring-boot/docs/current/reference/html/using-spring-boot.html#using-boot-devtools-remote) for information on how to connect to a remote application.
|
||||
|
||||
|
|
Before Width: | Height: | Size: 740 KiB |
After Width: | Height: | Size: 177 KiB |
Before Width: | Height: | Size: 197 KiB |
After Width: | Height: | Size: 41 KiB |
Before Width: | Height: | Size: 43 KiB |
After Width: | Height: | Size: 8.2 KiB |
Before Width: | Height: | Size: 384 KiB |
After Width: | Height: | Size: 83 KiB |
Before Width: | Height: | Size: 751 KiB |
After Width: | Height: | Size: 156 KiB |
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
description: Containerize Python apps using Docker
|
||||
keywords: Docker, getting started, Python, language
|
||||
title: What will you learn in this module?
|
||||
title: Python language-specific guide
|
||||
toc_min: 1
|
||||
toc_max: 2
|
||||
---
|
||||
|
|
|
@ -14,7 +14,7 @@ Docker Personal includes:
|
|||
|
||||
- Unlimited public repositories
|
||||
- Unlimited [Scoped Access Tokens](../security/for-developers/access-tokens.md)
|
||||
- Unlimited [collaborators](../docker-hub/repos/access/index.md#collaborators-and-their-role) for public repositories at no cost per month.
|
||||
- Unlimited [collaborators](../docker-hub/repos/access.md#collaborators-and-their-role) for public repositories at no cost per month.
|
||||
|
||||
Additionally, anonymous users get 100 pulls every 6 hours and users that sign in to Docker get 200 pulls every 6 hours.
|
||||
|
||||
|
|
|
@ -17,7 +17,7 @@ All Docker users can seek support through the following resources, where Docker
|
|||
- [Docker Desktop for Mac GitHub repo](https://github.com/docker/for-mac)
|
||||
- [Docker Desktop for Linux GitHub repo](https://github.com/docker/desktop-linux)
|
||||
- [Docker Community Forums](https://forums.docker.com/)
|
||||
- [Docker Community Slack](https://dockercommunity.slack.com/)
|
||||
- [Docker Community Slack](http://dockr.ly/comm-slack)
|
||||
|
||||
|
||||
## What support can I get?
|
||||
|
|
|
@ -48,7 +48,7 @@
|
|||
<div
|
||||
class="flex md:flex-col gap-2 rounded bg-white p-4 drop-shadow-sm dark:bg-gray-dark-200">
|
||||
<div class="flex flex-col gap-4 self-center items-center">
|
||||
<img class="w-[200px]" src="/assets/images/docker-future.png" />
|
||||
<img class="w-[200px]" src="/assets/images/docker-future.webp" />
|
||||
</div>
|
||||
<div class="flex flex-col">
|
||||
<div class="text-xl leading-snug text-gray-light-800 dark:text-white">
|
||||
|
@ -161,7 +161,7 @@
|
|||
<a class="link" href="/desktop/faqs/linuxfaqs/">Docker Desktop for Linux</a>
|
||||
</li>
|
||||
<li>
|
||||
<a class="link" href="/get-started/04_sharing_app/">Docker Single Sign-on</a>
|
||||
<a class="link" href="/faq/security/single-sign-on/faqs/">Docker Single Sign-on</a>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
|
Before Width: | Height: | Size: 1.3 MiB |
After Width: | Height: | Size: 79 KiB |