mirror of https://github.com/docker/docs.git
Improve alt text on images (#16484)
This commit is contained in:
Allie Sadler
GitHub
parent
85fcaa424f
commit
f956ab6552
|
|
@ -81,7 +81,7 @@ with the appropriate condition on the IAM role statement.
|
|||
> this stack requires a capability. This stack creates a role that will grant
|
||||
> Atomist read-only access to ECR resources.
|
||||
>
|
||||
> 
|
||||
> 
|
||||
|
||||
<div style="text-align: center">
|
||||
<table>
|
||||
|
|
@ -185,7 +185,7 @@ with the appropriate condition on the IAM role statement.
|
|||
Atomist tests the connection with your ECR registry. A green check mark
|
||||
displays beside the integration if a successful connection is made.
|
||||
|
||||
{:
|
||||
{:
|
||||
width="700px"}
|
||||
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ repositories for your Docker images.
|
|||
the
|
||||
[Atomist GitHub App](https://github.com/apps/atomist "Atomist GitHub App"){: target="blank" rel="noopener" class=""}.
|
||||
|
||||
{: width="700px" }
|
||||
{: width="700px" }
|
||||
|
||||
4. Install the app.
|
||||
|
||||
|
|
@ -39,7 +39,7 @@ repositories for your Docker images.
|
|||
5. In the repository selection menu, select what repositories you want Atomist
|
||||
to start watching.
|
||||
|
||||
{: width="500px" }
|
||||
{: width="500px" }
|
||||
|
||||
If you are just looking to evaluate Atomist, start by selecting a few
|
||||
repositories during evaluation. Once you are comfortable using Atomist, you
|
||||
|
|
|
|||
|
|
@ -77,12 +77,12 @@ rel="noopener" class=""}.
|
|||
target="blank" rel="noopener" class=""}, where you should see the image in
|
||||
the list.
|
||||
|
||||
{:
|
||||
{:
|
||||
width="700px"}
|
||||
|
||||
6. Select the image name. This gets you to the list of image tags.
|
||||
|
||||
{: width="700px"}
|
||||
{: width="700px"}
|
||||
|
||||
Since this is your first time indexing this image, the list only has one tag
|
||||
for now. When you integrate Atomist with your container registry, images and
|
||||
|
|
@ -90,7 +90,7 @@ rel="noopener" class=""}.
|
|||
|
||||
7. Select the tag name. This shows you the insights for this tag.
|
||||
|
||||
{:
|
||||
{:
|
||||
width="700px"}
|
||||
|
||||
In this view, you can see how many vulnerabilities this image has, their
|
||||
|
|
|
|||
|
|
@ -145,7 +145,7 @@ CONTAINER ID IMAGE COMMAND CREATED STATUS
|
|||
|
||||
You can also check from the browser that Nginx is running:
|
||||
|
||||
{:width="750px"}
|
||||
{:width="750px"}
|
||||
|
||||
## Building multi-platform images
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ It uses tools built into code editors that allows Docker to access code mounted
|
|||
|
||||
You can use Dev Environments through the intuitive GUI in Docker Dashboard or straight from you terminal with the new [`docker dev` CLI plugin](dev-cli.md).
|
||||
|
||||
{:width="700px"}
|
||||
{:width="700px"}
|
||||
|
||||
## How does it work?
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Extensions can be composed of 3 (optional) components:
|
|||
- a backend: one or many containerised services running in the Docker Desktop VM
|
||||
- executables: shell scripts or binaries that Docker Desktop copies on the host when installing the extension
|
||||
|
||||
|
||||
|
||||
|
||||
An extension doesn't necessarily need to have all these components, but at least one of them depending on the extension features.
|
||||
To configure and run those components, Docker Desktop uses a `metadata.json` file. See the
|
||||
|
|
|
|||
|
|
@ -209,7 +209,7 @@ provide you with type definitions for the extension APIs and auto-completion in
|
|||
npm install @docker/extension-api-client-types --save-dev
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
For example, you can use the `docker.cli.exec` function to get the list of all the containers via the `docker ps --all`
|
||||
command and display the result in a table.
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ To preview the extension in Docker Desktop, close and open Docker Dashboard once
|
|||
|
||||
The left-hand menu displays a new tab with the name of your extension.
|
||||
|
||||
|
||||
|
||||
|
||||
## What's next?
|
||||
|
||||
|
|
|
|||
|
|
@ -18,39 +18,39 @@ Use the [Docker Material UI Theme](https://www.npmjs.com/package/@docker/docker-
|
|||
|
||||
- Ensure the extension has both a light and dark theme. Using the components and styles as per the Docker style guide ensures that your extension meets the [level AA accessibility standard.](https://www.w3.org/WAI/WCAG2AA-Conformance){:target="_blank" rel="noopener" class="_"}.
|
||||
|
||||
|
||||
|
||||
|
||||
- Ensure that your extension icon is visible both in light and dark mode.
|
||||
|
||||
|
||||
|
||||
|
||||
- Ensure that the navigational behavior is consistent with the rest of Docker Desktop. Add a header to set the context for the extension.
|
||||
|
||||
|
||||
|
||||
|
||||
- Avoid embedding terminal windows. The advantage we have with Docker Desktop over the CLI is that we have the opportunity to provide rich information to users. Make use of this interface as much as possible.
|
||||
|
||||
{:height="=50%" width="50%"}
|
||||
{:height="=50%" width="50%"}
|
||||
|
||||
|
||||
|
||||
|
||||
## Build Features Natively
|
||||
|
||||
- In order not to disrupt the flow of users, avoid scenarios where the user has to navigate outside Docker Desktop, to the CLI or a webpage for example, in order to carry out certain functionalities. Instead, build features that are native to Docker Desktop.
|
||||
|
||||
{:height="=50%" width="50%"}
|
||||
{:height="=50%" width="50%"}
|
||||
|
||||
|
||||
|
||||
|
||||
## Break Down Complicated User Flows
|
||||
|
||||
- If a flow is too complicated or the concept is abstract, break down the flow into multiple steps with one simple call-to-action in each step. This helps when onboarding novice users to your extension
|
||||
|
||||
|
||||
|
||||
|
||||
- Where there are multiple call-to-actions, ensure you use the primary (filled button style) and secondary buttons (outline button style) to convey the importance of each action.
|
||||
|
||||
|
||||
|
||||
|
||||
## Onboarding New Users
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Extensions use image labels to provide additional information like title, descri
|
|||
|
||||
These information allow to display an overview of the extension to users so they can choose to install it:
|
||||
|
||||
|
||||
|
||||
|
||||
You can define [Image labels](../../../engine/reference/builder.md#label) in the extension's `Dockerfile`.
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ The Authorization Code grant type is used by confidential and public clients to
|
|||
|
||||
After the user returns to the client via the redirect URL, the application gets the authorization code from the URL and uses it to request an access token.
|
||||
|
||||
{: style=width:80% }
|
||||
{: style=width:80% }
|
||||
|
||||
The image above shows that:
|
||||
- The Docker Extension asks the user to authorize access to their data.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ You can seamlessly connect your favorite development tools to your application d
|
|||
|
||||
Anyone can use Docker Extensions and there is no limit to the number of extensions you can install.
|
||||
|
||||
{:width="750px"}
|
||||
{:width="750px"}
|
||||
|
||||
## What extensions are available?
|
||||
|
||||
|
|
|
|||
|
|
@ -141,4 +141,4 @@ Docker doesn't automatically mandate that developers re-launch and sign in once
|
|||
|
||||
In Docker Desktop, developers see the relevant settings grayed out and the message **Locked by your administrator**.
|
||||
|
||||
{:width="350px"}
|
||||
{:width="350px"}
|
||||
|
|
|
|||
|
|
@ -176,7 +176,7 @@ Docker Desktop does not start automatically after installation. To start Docker
|
|||
|
||||
1. Search for Docker, and select **Docker Desktop** in the search results.
|
||||
|
||||
{:width="300px"}
|
||||
{:width="300px"}
|
||||
|
||||
2. The Docker menu ({: .inline}) displays the Docker Subscription Service Agreement window.
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ To navigate to **Troubleshoot** either:
|
|||
- Select the Docker menu {: .inline} and then **Troubleshoot**
|
||||
- Select the **Troubleshoot** icon from the Docker Dashboard
|
||||
|
||||
{:width="600px"}
|
||||
{:width="600px"}
|
||||
|
||||
The Troubleshoot page contains the following options:
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ redirect_from:
|
|||
|
||||
When you open Docker Desktop, the Docker Dashboard displays.
|
||||
|
||||
{:width="750px"}
|
||||
{:width="750px"}
|
||||
|
||||
The **Containers** view provides a runtime view of all your containers and applications. It allows you to interact with containers and applications, and manage the lifecycle of your applications directly from your machine. This view also provides an intuitive interface to perform common actions to inspect, interact with, and manage your Docker objects including containers and Docker Compose-based applications. For more information, see [Explore running containers and applications](container.md).
|
||||
|
||||
|
|
|
|||
|
|
@ -18,11 +18,11 @@ To disable two-factor authentication, log in to your Docker Hub account. Click
|
|||
on your username and select **Account Settings**. Go to Security and click on
|
||||
**Disable 2FA**.
|
||||
|
||||
|
||||
|
||||
|
||||
You will be prompted to input your Docker ID password. Enter your password and
|
||||
click **Disable 2FA**.
|
||||
|
||||
{:width="250px"}
|
||||
{:width="250px"}
|
||||
|
||||
You have successfully disabled two-factor authentication.
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ entering a text code into your authenticator app. Once you have linked your
|
|||
authenticator app, it will give you a six-digit code to enter in text field.
|
||||
Click **Next**.
|
||||
|
||||
|
||||
|
||||
|
||||
You have successfully enabled two-factor authentication. The next time you log
|
||||
in to your Docker Hub account, you will be asked for a security code.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ on your username and select **Account Settings**. Go to **Security** and **Click
|
|||
|
||||
Enter your password.
|
||||
|
||||
{:width="250px"}
|
||||
{:width="250px"}
|
||||
|
||||
Your new recovery code will be displayed. Remember to save your recovery code
|
||||
and store it somewhere safe.
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ To create your access token:
|
|||
will be used, or set a purpose for the token. You can view the following access
|
||||
permissions from the drop-down:
|
||||
|
||||
{:width="700px"}
|
||||
{:width="700px"}
|
||||
|
||||
The access permissions are scopes that set restrictions in your
|
||||
repositories. For example, for Read & Write permissions, an automation
|
||||
|
|
@ -60,7 +60,7 @@ To create your access token:
|
|||
5. Copy the token that appears on the screen and save it. You will not be able
|
||||
to retrieve the token once you close this prompt.
|
||||
|
||||
{:width="700px"}
|
||||
{:width="700px"}
|
||||
|
||||
## Use an access token
|
||||
|
||||
|
|
@ -85,12 +85,12 @@ You can rename, activate, deactivate, or delete a token as needed.
|
|||
This page shows an overview of all your tokens. You can also view the number
|
||||
of tokens that are activated and deactivated in the toolbar.
|
||||
|
||||
{:width="700px"}
|
||||
{:width="700px"}
|
||||
|
||||
2. Select a token and click **Delete** or **Edit**, or use the menu on
|
||||
the far right of a token row to bring up the edit screen. You can also
|
||||
select multiple tokens to delete at once.
|
||||
|
||||
{:width="700px"}
|
||||
{:width="700px"}
|
||||
|
||||
3. After modifying the token, click the **Save** button to save your changes.
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ By default, all activities that occur at organization and repository levels are
|
|||
|
||||
Click the **All Activities** drop-down list to view activities that are specific to an organization or a repository. After choosing **Organization** or **Repository**, you can further refine the results using the **All Actions** drop-down list. If you select the **Activities** tab from the **Repository** view, you can only filter repository-level activities.
|
||||
|
||||
{:width="600px"}
|
||||
{:width="600px"}
|
||||
|
||||
|
||||
## Audit logs event definitions
|
||||
|
|
|
|||
|
|
@ -179,7 +179,7 @@ bar chart of the build queue times and durations. Both views display the
|
|||
pending, in progress, successful, and failed builds for any tag of the
|
||||
repository.
|
||||
|
||||
|
||||
|
||||
|
||||
From either location, you can select a build job to view its build report. The
|
||||
build report shows information about the build job. This includes the source
|
||||
|
|
@ -191,7 +191,7 @@ repository and branch (or tag), the build logs, the build duration, creation tim
|
|||
> refresh the Builds page. With the in-progress build logs, you can debug your
|
||||
> builds before they're finished.
|
||||
|
||||
|
||||
|
||||
|
||||
## Cancel or retry a build
|
||||
|
||||
|
|
@ -200,7 +200,7 @@ report link on the General tab and on the Builds tab. You can also click the
|
|||
**Cancel** on the build report page, or from the Timeline tab's logs
|
||||
display for the build.
|
||||
|
||||
|
||||
|
||||
|
||||
## Failing builds
|
||||
|
||||
|
|
|
|||
|
|
@ -166,7 +166,7 @@ To give a team access to a repository
|
|||
4. Choose a permission from the **Permissions** drop-down list and click
|
||||
**Add**.
|
||||
|
||||
{:width="700px"}
|
||||
{:width="700px"}
|
||||
|
||||
### View a team's permissions for all repositories
|
||||
|
||||
|
|
|
|||
|
|
@ -93,13 +93,13 @@ To create a repository:
|
|||
3. Name it **<your-username>/my-private-repo**.
|
||||
4. Set the visibility to **Private**.
|
||||
|
||||
|
||||
|
||||
|
||||
5. Click **Create**.
|
||||
|
||||
You've created your first repository. You should see:
|
||||
|
||||
|
||||
|
||||
|
||||
### Step 3: Download and install Docker Desktop
|
||||
|
||||
|
|
@ -175,7 +175,7 @@ Docker image locally.
|
|||
|
||||
5. Your repository in Docker Hub should now display a new `latest` tag under **Tags**:
|
||||
|
||||
|
||||
|
||||
|
||||
Congratulations! You've successfully:
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ see the [organizations documentation](../../../docker-hub/orgs.md#create-an-orga
|
|||
Docker Hub's individual repositories view shows you the available tags and the
|
||||
size of the associated image. Go to the **Repositories** view and select repository to see its tags. To view individual tags, select the **Tags** tab.
|
||||
|
||||
|
||||
|
||||
|
||||
Image sizes are the cumulative space taken up by the image and all its parent
|
||||
images. This is also the disk space used by the contents of the `.tar` file
|
||||
|
|
@ -48,7 +48,7 @@ To delete a tag, select the corresponding checkbox and select **Delete** from th
|
|||
|
||||
You can select a tag's digest to view more details.
|
||||
|
||||
|
||||
|
||||
|
||||
## Searching for repositories
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ When configuring repositories, your private repositories let you keep your conta
|
|||
|
||||
You can make an existing repository private by going to its **Settings** tab and select **Make private**.
|
||||
|
||||
{: style="max-width: 60%"}
|
||||
{: style="max-width: 60%"}
|
||||
|
||||
You get one free private repository with your Docker Hub user account (not
|
||||
available for organizations you're a member of). If you need more private
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ To create a private repository, navigate to Docker Hub and select **Repositories
|
|||
>
|
||||
> To update your public repository to private, navigate to your repository, select **Settings** and **Make private**.
|
||||
|
||||
{: style="max-width: 60%"}
|
||||
{: style="max-width: 60%"}
|
||||
|
||||
## Deleting a repository
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ SSO must be set up and be functional for your organization before you start conf
|
|||
|
||||
Before you make SCIM configuration changes in your IdP, navigate to [Docker Hub](https://hub.docker.com){: target="_blank" rel="noopener" class="_"} and select **Organizations** > **Settings** > **Security**. SCIM is locked until you complete the SSO configuration and verify your company domain. Enable SCIM and access your Base URL and API Token. You can also generate a new API token.
|
||||
|
||||
{:width="700px"}
|
||||
{:width="700px"}
|
||||
|
||||
### Okta
|
||||
|
||||
|
|
@ -37,16 +37,16 @@ Before you make SCIM configuration changes in your IdP, navigate to [Docker Hub]
|
|||
* **Supported Provisioning actions**: select **Push New Users**, **Push Profile Updates**
|
||||
* **Authorization/Bearer**: SCIM API Token from Docker Hub
|
||||
|
||||
{:width="700px"}
|
||||
{:width="700px"}
|
||||
|
||||
4. Click **Test Connection Configuration** to complete the configuration and **Save**.
|
||||
5. Once configured, you must enable synchronization. Navigate to **Provisioning** > **To App** > **Edit**, and enable **Create Users**, **Update User Attributes** and **Deactivates Users**, and **Save**.
|
||||
|
||||
{:width="700px"}
|
||||
{:width="700px"}
|
||||
|
||||
6. Remove all fields that aren't supported from your **Docker Hub Attributes Mappings**.
|
||||
|
||||
{:width="700px"}
|
||||
{:width="700px"}
|
||||
|
||||
The synchronization of user data is now automated, and the members in your Docker organization will now be automatically provisioned, updated, and de-provisioned based on the access control managed through your identity provider, Okta.
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ You can use webhooks to cause an action in another service in response to a push
|
|||
|
||||
Configure webhooks through the "Webhooks" tab on your Docker Hub repository:
|
||||
|
||||
|
||||
|
||||
|
||||
### Create Webhooks
|
||||
|
||||
|
|
@ -16,13 +16,13 @@ To create a webhook, visit the webhooks tab for your repository. Then:
|
|||
1. Provide a name for the webhooks
|
||||
2. Provide a destination webhook URL. This is where webhook POST requests will be delivered:
|
||||
|
||||
|
||||
|
||||
|
||||
### View Webhook delivery history
|
||||
|
||||
You can view Webhook Delivery History by clicking on the submenu of the webhook and then clicking "View History"
|
||||
|
||||
|
||||
|
||||
|
||||
You can then view the delivery history, and whether delivering the POST request was successful or failed:
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ the lifetime of the node in the current swarm.
|
|||
The diagram below illustrates how manager nodes and worker nodes encrypt
|
||||
communications using a minimum of TLS 1.2.
|
||||
|
||||
|
||||
|
||||
|
||||
The example below shows the information from a certificate from a worker node:
|
||||
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ For example, imagine you want to load balance between three instances of an HTTP
|
|||
listener. The diagram below shows an HTTP listener service with three replicas.
|
||||
Each of the three instances of the listener is a task in the swarm.
|
||||
|
||||
|
||||
|
||||
|
||||
A container is an isolated process. In the swarm mode model, each task invokes
|
||||
exactly one container. A task is analogous to a “slot” where the scheduler
|
||||
|
|
@ -66,7 +66,7 @@ current version of Docker only supports container tasks.
|
|||
The diagram below shows how swarm mode accepts service create requests and
|
||||
schedules tasks to worker nodes.
|
||||
|
||||
|
||||
|
||||
|
||||
### Pending services
|
||||
|
||||
|
|
@ -116,7 +116,7 @@ swarm.
|
|||
The diagram below shows a three-service replica in yellow and a global service
|
||||
in gray.
|
||||
|
||||
|
||||
|
||||
|
||||
## Learn more
|
||||
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ the node. For externally routable IP addresses, the port is available from
|
|||
outside the host. For all other IP addresses the access is only available from
|
||||
within the host.
|
||||
|
||||
|
||||
|
||||
|
||||
You can publish a port for an existing service using the following command:
|
||||
|
||||
|
|
@ -198,7 +198,7 @@ You can configure an external load balancer to route requests to a swarm
|
|||
service. For example, you could configure [HAProxy](https://www.haproxy.org) to
|
||||
balance requests to an nginx service published to port 8080.
|
||||
|
||||
|
||||
|
||||
|
||||
In this case, port 8080 must be open between the load balancer and the nodes in
|
||||
the swarm. The swarm nodes can reside on a private network that is accessible to
|
||||
|
|
|
|||
|
|
@ -776,7 +776,7 @@ possible to fulfill.
|
|||
|
||||
This diagram illustrates how placement preferences work:
|
||||
|
||||
|
||||
|
||||
|
||||
When updating a service with `docker service update`, `--placement-pref-add`
|
||||
appends a new placement preference after all existing placement preferences.
|
||||
|
|
|
|||
|
|
@ -126,7 +126,7 @@ Now that you have an image, you can run the application in a [container](../get-
|
|||
2. After a few seconds, open your web browser to [http://localhost:3000](http://localhost:3000){:target="_blank" rel="noopener" class="_"}.
|
||||
You should see your app.
|
||||
|
||||
{: style="width:450px;margin-top:20px;"}
|
||||
{: style="width:450px;margin-top:20px;"}
|
||||
{: .text-center }
|
||||
|
||||
3. Go ahead and add an item or two and see that it works as you expect. You can mark items as complete and remove items. Your frontend is successfully storing items in the backend.
|
||||
|
|
|
|||
|
|
@ -84,7 +84,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
|
||||
|
||||
|
|
|
|||
|
|
@ -264,7 +264,7 @@ $ docker run \
|
|||
|
||||
Let's test that the application works and is connecting to the database. Using a web browser, access `http://localhost:5000`. A page similar to the following image appears.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Connect Adminer and populate the database
|
||||
|
|
@ -284,7 +284,7 @@ Using a web browser, access `http://localhost:8080`.
|
|||
|
||||
The Adminer login page appears.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Specify the following in the login page and then click **Login**:
|
||||
|
|
@ -296,21 +296,21 @@ Specify the following in the login page and then click **Login**:
|
|||
|
||||
The `Schema: public` page appears.
|
||||
|
||||
|
||||
|
||||
|
||||
In `Tables and views`, click `Students`. The `Table: Students` page appears.
|
||||
|
||||
|
||||
|
||||
|
||||
Click `New item`. The `Insert: Students` page appears.
|
||||
|
||||
|
||||
|
||||
|
||||
Specify a `LastName`, `FirstMidName`, and `EnrollmentDate`. Click `Save`.
|
||||
|
||||
Verify that the student name appears in the application. Use a web browser to access `http://localhost:5000`.
|
||||
|
||||
|
||||
|
||||
|
||||
List and then stop the application, database, and Adminer containers.
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ $ docker run --publish 5000:80 dotnet-docker
|
|||
|
||||
Now, let's access `http://localhost:5000` in a browser. You should see a page similar to the following image.
|
||||
|
||||
|
||||
|
||||
|
||||
Success! We were able to connect to the application running inside of our container on port 80.
|
||||
|
||||
|
|
@ -57,7 +57,7 @@ Docker started our container in the background and printed the Container ID on t
|
|||
|
||||
Again, let’s make sure that our container is running properly. In a web browser, access `http://localhost:5000`. You should see a page similar to the following image.
|
||||
|
||||
|
||||
|
||||
|
||||
## List containers
|
||||
|
||||
|
|
|
|||
|
|
@ -184,7 +184,7 @@ We pass the `--build` flag so Docker compiles our image and then starts it.
|
|||
|
||||
If all goes well, you should see something similar:
|
||||
|
||||
{:width="800px"}
|
||||
{:width="800px"}
|
||||
|
||||
Now let’s test our API endpoint. Run the following curl command:
|
||||
|
||||
|
|
@ -206,7 +206,7 @@ We’ll use the debugger that comes with the Chrome browser. Open Chrome on your
|
|||
|
||||
It opens the following screen.
|
||||
|
||||
{:width="800px"}
|
||||
{:width="800px"}
|
||||
|
||||
Click the **Open dedicated DevTools for Node** link. This opens the DevTools that are connected to the running Node.js process inside our container.
|
||||
|
||||
|
|
@ -222,7 +222,7 @@ Add the following code above the existing `server.use()` statement, and save the
|
|||
|
||||
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.
|
||||
|
||||
{:width="800px"}
|
||||
{:width="800px"}
|
||||
|
||||
Navigate back to the Chrome DevTools and set a breakpoint on the line containing the `return res.json({ "foo": "bar" })` statement, and then run the following curl command to trigger the breakpoint.
|
||||
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ To help understand how this mode interacts with other hosts, the following
|
|||
figure shows the same layer 2 segment between two Docker hosts that applies to
|
||||
and IPvlan L2 mode.
|
||||
|
||||
|
||||
|
||||
|
||||
The following will create the exact same network as the network `db_net` created
|
||||
earlier, with the driver defaults for `--gateway=192.168.1.1` and `-o ipvlan_mode=l2`.
|
||||
|
|
@ -161,7 +161,7 @@ practice of layered defense in depth architectures. VLANs or the equivocal VNI
|
|||
(Virtual Network Identifier) when using the Overlay driver, are the first step
|
||||
in isolating tenant traffic.
|
||||
|
||||
|
||||
|
||||
|
||||
The Linux sub-interface tagged with a VLAN can either already exist or will be
|
||||
created when you call a `docker network create`. `docker network rm` will delete
|
||||
|
|
@ -293,7 +293,7 @@ upstream network will not know about without route distribution. For those
|
|||
curious how IPvlan L3 will fit into container networking, see the following
|
||||
examples.
|
||||
|
||||
|
||||
|
||||
|
||||
IPvlan L3 mode drops all broadcast and multicast traffic. This reason alone
|
||||
makes IPvlan L3 mode a prime candidate for those looking for massive scale and
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ To remove a user from an organization:
|
|||
|
||||
When you disable SSO, you can delete the connection to remove the configuration settings and the added domains. Once you delete this connection, it can't be undone. Users must authenticate with their Docker ID and password or create a password reset if they don't have one.
|
||||
|
||||
{:width="500px"}
|
||||
{:width="500px"}
|
||||
|
||||
## FAQs
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ available. If you are developing new Docker applications, consider using
|
|||
[named volumes](volumes.md) instead. You can't use Docker CLI commands to directly
|
||||
manage bind mounts.
|
||||
|
||||
|
||||
|
||||
|
||||
## Choose the -v or --mount flag
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ in the container's filesystem.
|
|||
An easy way to visualize the difference among volumes, bind mounts, and `tmpfs`
|
||||
mounts is to think about where the data lives on the Docker host.
|
||||
|
||||
|
||||
|
||||
|
||||
- **Volumes** are stored in a part of the host filesystem which is _managed by
|
||||
Docker_ (`/var/lib/docker/volumes/` on Linux). Non-Docker processes should not
|
||||
|
|
|
|||
|
|
@ -167,14 +167,14 @@ nested and snapshotted. The diagram below shows 4 subvolumes. 'Subvolume 2' and
|
|||
'Subvolume 3' are nested, whereas 'Subvolume 4' shows its own internal directory
|
||||
tree.
|
||||
|
||||
|
||||
|
||||
|
||||
Only the base layer of an image is stored as a true subvolume. All the other
|
||||
layers are stored as snapshots, which only contain the differences introduced
|
||||
in that layer. You can create snapshots of snapshots as shown in the diagram
|
||||
below.
|
||||
|
||||
|
||||
|
||||
|
||||
On disk, snapshots look and feel just like subvolumes, but in reality they are
|
||||
much smaller and more space-efficient. Copy-on-write is used to maximize storage
|
||||
|
|
@ -182,7 +182,7 @@ efficiency and minimize layer size, and writes in the container's writable layer
|
|||
are managed at the block level. The following image shows a subvolume and its
|
||||
snapshot sharing data.
|
||||
|
||||
|
||||
|
||||
|
||||
For maximum efficiency, when a container needs more space, it is allocated in
|
||||
*chunks* of roughly 1 GB in size.
|
||||
|
|
|
|||
|
|
@ -740,7 +740,7 @@ container, it is a snapshot of the image the container is based on. The followin
|
|||
example shows a Docker host with two running containers. The first is a `ubuntu`
|
||||
container and the second is a `busybox` container.
|
||||
|
||||
|
||||
|
||||
|
||||
## How container reads and writes work with `devicemapper`
|
||||
|
||||
|
|
@ -750,7 +750,7 @@ With `devicemapper`, reads happen at the block level. The diagram below shows
|
|||
the high level process for reading a single block (`0x44f`) in an example
|
||||
container.
|
||||
|
||||
|
||||
|
||||
|
||||
An application makes a read request for block `0x44f` in the container. Because
|
||||
the container is a thin snapshot of an image, it doesn't have the block, but it
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@ stored in this container layer, multiple containers can share access to the same
|
|||
underlying image and yet have their own data state. The diagram below shows
|
||||
multiple containers sharing the same Ubuntu 15.04 image.
|
||||
|
||||
|
||||
|
||||
|
||||
Docker uses storage drivers to manage the contents of the image layers and the
|
||||
writable container layer. Each storage driver handles the implementation
|
||||
|
|
|
|||
|
|
@ -248,7 +248,7 @@ The unified view is exposed through a directory called `merged` which is
|
|||
effectively the containers mount point. The diagram shows how Docker constructs
|
||||
map to OverlayFS constructs.
|
||||
|
||||
|
||||
|
||||
|
||||
Where the image layer and the container layer contain the same files, the
|
||||
container layer "wins" and obscures the existence of the same files in the image
|
||||
|
|
|
|||
|
|
@ -150,7 +150,7 @@ ZFS uses the following objects:
|
|||
|
||||
The process of creating a clone:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
1. A read-only snapshot is created from the filesystem.
|
||||
|
|
@ -175,7 +175,7 @@ on a ZFS Snapshot of the top layer of the image it's created from.
|
|||
The diagram below shows how this is put together with a running container based
|
||||
on a two-layer image.
|
||||
|
||||
|
||||
|
||||
|
||||
When you start a container, the following steps happen in order:
|
||||
|
||||
|
|
@ -209,7 +209,7 @@ the dataset it was created from (the snapshots of its parent layers). Read
|
|||
operations are fast, even if the data being read is from a deep layer.
|
||||
This diagram illustrates how block sharing works:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Writing files
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ container's writable layer, because a volume does not increase the size of the
|
|||
containers using it, and the volume's contents exist outside the lifecycle of a
|
||||
given container.
|
||||
|
||||
|
||||
|
||||
|
||||
If your container generates non-persistent state data, consider using a
|
||||
[tmpfs mount](tmpfs.md) to avoid storing the data anywhere permanently, and to
|
||||
|
|
|
|||
Loading…
Reference in New Issue