mirror of
https://github.com/docker/docs.git
synced 2026-06-19 07:35:16 +00:00
Add alt text to images which are missing it (#5047)
Signed-off-by: Bhavin Gandhi <bhavin7392@gmail.com>
This commit is contained in:
Bhavin Gandhi
committed by
Misty Stanley-Jones
Misty Stanley-Jones
parent
86bd21e88d
commit
3123389ccb
+1
-1
@@ -12,4 +12,4 @@ DTR repositories, permissions, and settings.
|
||||
To get access to interactive documentation, in your **DTR UI**, click
|
||||
on the **top-right menu** and choose **API docs**.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -62,7 +62,7 @@ Now that UCP is installed, you need to license it. In your browser, navigate
|
||||
to the UCP web UI, log in with your administrator credentials and upload your
|
||||
license.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
[Get a free trial license if you don't have one](https://store.docker.com/editions/enterprise/docker-ee-trial).
|
||||
|
||||
@@ -71,11 +71,11 @@ license.
|
||||
Join more nodes so that you can manage them from UCP.
|
||||
Go to the UCP web UI and navigate to the **Nodes** page.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
Click the **Add Node button** to add a new node.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
|
||||
Check **Add node as a manager** to join the node as a manager
|
||||
|
||||
@@ -63,7 +63,7 @@ the code repository service where the image's source code is stored.
|
||||
Docker's infrastructure, select a builder size to run the build
|
||||
process on. This hosted build service is free while it is in Beta.
|
||||
|
||||
|
||||
|
||||
|
||||
6. If in the previous step you selected **Build on Docker
|
||||
Cloud’s infrastructure**, then you are given the option to select the
|
||||
|
||||
@@ -36,7 +36,7 @@ To opt in:
|
||||
|
||||
3. Check **Monitor with Docker Security Scanning** to add the service to your plan.
|
||||
|
||||
|
||||
|
||||
|
||||
The scanning process begins immediately for the three most recent tags in each
|
||||
of your private repositories. The scan results should be available within 48
|
||||
|
||||
@@ -24,10 +24,10 @@ need to link your source code provider.
|
||||
|
||||
3. Click the plug icon for the source provider you want to link.
|
||||
|
||||
|
||||
|
||||
|
||||
4. Review the settings for the **Docker Cloud Builder** OAuth application.
|
||||
|
||||
|
||||
|
||||
>**Note**: If you are the owner of any Github organizations, you might see
|
||||
options to grant Docker Cloud access to them from this screen. You can also
|
||||
@@ -56,7 +56,7 @@ from Docker Cloud, *and* from your GitHub account.
|
||||
4. Go to your GitHub account's **Settings** page.
|
||||
|
||||
5. Click **OAuth applications** in the left navigation bar.
|
||||
|
||||
|
||||
|
||||
6. Click **Revoke** next to the Docker Cloud Builder application.
|
||||
|
||||
@@ -78,7 +78,7 @@ case, a **Grant access** button appears next to the organization name in the
|
||||
link accounts screen, as shown below. If this button does not appear, you must
|
||||
manually grant the application's access.
|
||||
|
||||
|
||||
|
||||
|
||||
To manually grant Docker Cloud access to a GitHub organization:
|
||||
|
||||
@@ -97,7 +97,7 @@ section at the lower left.
|
||||
5. Click the pencil icon next to Docker Cloud Builder.
|
||||
|
||||
6. Click **Grant access** next to the organization.
|
||||
|
||||
|
||||
|
||||
### Revoke access to a GitHub organization
|
||||
|
||||
@@ -108,7 +108,7 @@ To revoke Docker Cloud's access to an organization's GitHub repositories:
|
||||
3. From the Organization Profile menu, click **Third-party access**.
|
||||
The page displays a list of third party applications and their access status.
|
||||
4. Click the pencil icon next to Docker Cloud Builder.
|
||||
|
||||
|
||||
5. On the next page, click **Deny access**.
|
||||
|
||||
## Link to a Bitbucket user account
|
||||
@@ -121,7 +121,7 @@ To revoke Docker Cloud's access to an organization's GitHub repositories:
|
||||
|
||||
4. Click the plug icon for the source provider you want to link.
|
||||
|
||||
|
||||
|
||||
|
||||
5. If necessary, log in to Bitbucket.
|
||||
|
||||
@@ -151,4 +151,4 @@ unlink it both from Docker Cloud, *and* from your Bitbucket account.
|
||||
> **Note**: Each repository that is configured as an automated build source
|
||||
contains a webhook that notifies Docker Cloud of changes in the repository. This
|
||||
webhook is not automatically removed when you revoke access to a source code
|
||||
provider.
|
||||
provider.
|
||||
|
||||
@@ -30,7 +30,7 @@ To store your images in Docker Cloud, you create a repository. All individual us
|
||||
> **Note**: You do not need to set up automated builds right away, and you can change the build settings at any time after the repository is created. If you choose not to enable automated builds, you can still push images to the repository using the `docker` or `docker-cloud` CLI.
|
||||
6. Click **Create**.
|
||||
|
||||
|
||||
|
||||
|
||||
### Repositories for Organizations
|
||||
|
||||
@@ -126,7 +126,7 @@ registry.
|
||||
|
||||
For example, `registry.com/namespace/reponame` where `registry.com` is the
|
||||
hostname of the registry.
|
||||
|
||||
|
||||
|
||||
5. Enter credentials for the registry.
|
||||
|
||||
|
||||
@@ -23,7 +23,7 @@ swarm.
|
||||
2. Click **Swarms** in the top navigation, and click the name of the swarm you want to connect to.
|
||||
3. Copy the command provided in the dialog that appears.
|
||||
|
||||
|
||||
|
||||
|
||||
4. In a terminal window connected to your local Docker Engine, paste the command, and press **Enter**.
|
||||
|
||||
|
||||
@@ -80,7 +80,7 @@ the new policy to your existing role by following the instructions
|
||||
|
||||
The ARN string should look something like `arn:aws:iam::123456789123:role/dockercloud-swarm-role`. You'll use the ARN in the next step.
|
||||
|
||||
|
||||
|
||||
|
||||
Now skip down to the topic on how to
|
||||
[Add your AWS account credentials to Docker Cloud](#add-your-aws-account-credentials-to-docker-cloud).
|
||||
@@ -126,12 +126,12 @@ Role ARN, go back to Docker Cloud to connect the account.
|
||||
1. In Docker Cloud, click the account menu at the upper right and select **Cloud settings**.
|
||||
2. In the **Service providers** section, click the plug icon next to Amazon Web Services.
|
||||
|
||||
|
||||
|
||||
|
||||
3. Enter the full `Role ARN` for the role you just created.
|
||||
4. Click **Save**.
|
||||
|
||||
|
||||
|
||||
|
||||
You are now ready to deploy a swarm!
|
||||
|
||||
|
||||
@@ -24,7 +24,7 @@ You can click a resource from the Dashboard and find the subscription ID under
|
||||
**Billing -> Subscriptions -> Subscription ID** or simply click
|
||||
**Subscriptions**, then click a subscription in the list to drill down.
|
||||
|
||||
|
||||
|
||||
|
||||
When you are ready to add your subscription ID to Docker Cloud,
|
||||
copy it from your Azure Dashboard.
|
||||
@@ -39,10 +39,10 @@ select **Cloud settings**.
|
||||
2. In the **Service Providers** section, click the plug icon next to
|
||||
Microsoft Azure.
|
||||
|
||||
|
||||
|
||||
|
||||
>**Tip:** If you are a member of an Azure Organization, your
|
||||
admninistrator must first link to Docker Cloud as described in
|
||||
administrator must first link to Docker Cloud as described in
|
||||
[Link an Azure Organization as Global Admin](#link-an-azure-organization-as-global-admin).
|
||||
|
||||
3. Provide your subscription ID and click **Save**.
|
||||
@@ -51,7 +51,7 @@ Microsoft Azure.
|
||||
the two accounts. Your Azure login credentials will automatically populate
|
||||
to Docker Cloud under **Service Providers -> Microsoft Azure**.
|
||||
|
||||
|
||||
|
||||
|
||||
## Enable your Azure subscription for Docker Cloud
|
||||
|
||||
|
||||
@@ -57,7 +57,7 @@ also store pre-built images, or link to your source code so it can build the
|
||||
code into Docker images, and optionally test the resulting images before pushing
|
||||
them to a repository.
|
||||
|
||||
|
||||
|
||||
|
||||
### Swarm Management (Beta Swarm Mode)
|
||||
|
||||
@@ -67,7 +67,7 @@ provision swarms to your cloud providers. Your Docker ID authenticates and
|
||||
securely accesses personal or team swarms. Docker Cloud allows you to connect
|
||||
your local Docker Engine to any swarm you have access to in Docker Cloud.
|
||||
|
||||
|
||||
|
||||
|
||||
### Infrastructure management (Standard Mode)
|
||||
|
||||
@@ -76,7 +76,7 @@ Docker Cloud allows you to link to your infrastructure or cloud services
|
||||
provider so you can provision new nodes automatically. Once you have nodes set
|
||||
up, you can deploy images directly from Docker Cloud repositories.
|
||||
|
||||
|
||||
|
||||
|
||||
### Services, Stacks, and Applications (Standard Mode)
|
||||
|
||||
@@ -86,4 +86,4 @@ containers created from an image), or use Docker Cloud's
|
||||
[stackfiles](apps/stacks.md) to combine it with other services and
|
||||
microservices, to form a full application.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -17,13 +17,13 @@ node can be used for administrating the swarm.
|
||||
Once you've deployed Docker on Azure, go to the "Outputs" section of the
|
||||
resource group deployment.
|
||||
|
||||
|
||||
|
||||
|
||||
The "SSH Targets" output is a URL to a blade that describes the IP address
|
||||
(common across all the manager nodes) and the SSH port (unique for each manager
|
||||
node) that you can use to log in to each manager node.
|
||||
|
||||
|
||||
|
||||
|
||||
Obtain the public IP and/or port for the manager node as instructed above and
|
||||
use the provided SSH key to begin administrating your swarm and the unique port associated with a manager:
|
||||
|
||||
@@ -77,7 +77,7 @@ To view the Docker Security Scanning results:
|
||||
You can view Official Images even while logged out, however the scan results are only available once you log in.
|
||||
2. Navigate to the official repository whose security scan you want to view.
|
||||
3. Click the `Tags` tab to see a list of tags and their security scan summaries.
|
||||
|
||||
|
||||
|
||||
You can click into a tag's detail page to see more information about which
|
||||
layers in the image and which components within the layer are vulnerable.
|
||||
|
||||
@@ -69,7 +69,7 @@ interface.
|
||||
>
|
||||
> $ sysctl net.ipv6.conf.eth0.accept_ra=2
|
||||
|
||||
|
||||
|
||||
|
||||
Every new container will get an IPv6 address from the defined subnet, and a
|
||||
default route will be added on `eth0` in the container via the address specified
|
||||
@@ -104,7 +104,7 @@ Often servers or virtual machines get a `/64` IPv6 subnet assigned (e.g.
|
||||
Docker a `/80` subnet while using a separate `/80` subnet for other applications
|
||||
on the host:
|
||||
|
||||
|
||||
|
||||
|
||||
In this setup the subnet `2001:db8:23:42::/64` with a range from
|
||||
`2001:db8:23:42:0:0:0:0` to `2001:db8:23:42:ffff:ffff:ffff:ffff` is attached to
|
||||
@@ -152,7 +152,7 @@ The Docker subnet is within the subnet managed by your router and connected to
|
||||
found within the router subnet, and the router can communicate with these
|
||||
containers directly.
|
||||
|
||||
|
||||
|
||||
|
||||
When the router wants to send an IPv6 packet to the first container, it
|
||||
transmits a _neighbor solicitation request_, asking "Who has `2001:db8::c009`?"
|
||||
@@ -197,7 +197,7 @@ Using routable IPv6 addresses allows you to realize communication between
|
||||
containers on different hosts. Let's have a look at a simple Docker IPv6 cluster
|
||||
example:
|
||||
|
||||
|
||||
|
||||
|
||||
The Docker hosts are in the `2001:db8:0::/64` subnet. Host1 is configured to
|
||||
provide addresses from the `2001:db8:1::/64` subnet to its containers. It has
|
||||
@@ -246,7 +246,7 @@ routing information about the Docker subnets. When you add or remove a host to
|
||||
this environment you just have to update the routing table in the router - not
|
||||
on every host.
|
||||
|
||||
|
||||
|
||||
|
||||
In this scenario containers of the same host can communicate directly with each
|
||||
other. The traffic between containers on different hosts will be routed via
|
||||
|
||||
@@ -332,7 +332,7 @@ needed.
|
||||
network when you launched it and you connected it to the `isolated_nw` in
|
||||
step 3.
|
||||
|
||||
|
||||
|
||||
|
||||
eth0 Link encap:Ethernet HWaddr 02:42:AC:11:00:03
|
||||
|
||||
|
||||
@@ -198,7 +198,7 @@ own Btrfs subvolume or snapshot. The base layer of an image is stored as a
|
||||
subvolume whereas child image layers and containers are stored as snapshots.
|
||||
This is shown in the diagram below.
|
||||
|
||||
|
||||
|
||||
|
||||
The high level process for creating images and containers on Docker hosts
|
||||
running the `btrfs` driver is as follows:
|
||||
|
||||
@@ -43,7 +43,7 @@ new files, modifying existing files, and deleting files, are written to this thi
|
||||
writable container layer. The diagram below shows a container based on the Ubuntu
|
||||
15.04 image.
|
||||
|
||||
|
||||
|
||||
|
||||
A _storage driver_ handles the details about the way these layers interact with
|
||||
each other. Different storage drivers are available, which have advantages
|
||||
@@ -61,7 +61,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.
|
||||
|
||||
|
||||
|
||||
|
||||
> **Note**: If you need multiple images to have shared access to the exact
|
||||
> same data, store this data in a Docker volume and mount it into your
|
||||
@@ -407,7 +407,7 @@ storage area (`/var/lib/docker/...`). There is also a single shared data volume
|
||||
located at `/data` on the Docker host. This is mounted directly into both
|
||||
containers.
|
||||
|
||||
|
||||
|
||||
|
||||
Data volumes reside outside of the local storage area on the Docker host,
|
||||
further reinforcing their independence from the storage driver's control. When
|
||||
|
||||
@@ -87,11 +87,11 @@ docker node update --availability active <node>
|
||||
Once you've upgraded the Docker Engine running on all the nodes, upgrade UCP.
|
||||
You can do this from the UCP web UI.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
Click on the banner, and choose the version you want to upgrade to.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
Once you click **Upgrade UCP**, the upgrade starts. If you want you can upgrade
|
||||
UCP from the CLI instead. [Learn more](/datacenter/ucp/2.2/guides/admin/install/upgrade.md).
|
||||
@@ -100,7 +100,7 @@ UCP from the CLI instead. [Learn more](/datacenter/ucp/2.2/guides/admin/install/
|
||||
|
||||
Log in into the DTR web UI to check if there's a new version available.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
Then follow these [instructions to upgrade DTR](/datacenter/dtr/2.3/guides/admin/upgrade.md).
|
||||
When this is finished, your Docker EE has been upgraded.
|
||||
|
||||
@@ -10,7 +10,7 @@ pushes and pulls and layer pushes and pulls. These actions are serialized into
|
||||
events. The events are queued into a registry-internal broadcast system which
|
||||
queues and dispatches events to [_Endpoints_](notifications.md#endpoints).
|
||||
|
||||
|
||||
|
||||
|
||||
## Endpoints
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ Swarm Manager, and a Certificate Authority as shown below. All the Docker Engine
|
||||
hosts (`client`, `swarm`, `node1`, and `node2`) have a copy of the
|
||||
CA's certificate as well as their own key-pair signed by the CA.
|
||||
|
||||
|
||||
|
||||
|
||||
You will complete the following steps in this procedure:
|
||||
|
||||
@@ -307,7 +307,7 @@ follows on each node:
|
||||
|
||||
When the copying is complete, each machine should have the following keys.
|
||||
|
||||
|
||||
|
||||
|
||||
Each node in your infrastructure should have the following files in the
|
||||
`/home/ubuntu/.certs/` directory:
|
||||
|
||||
@@ -138,7 +138,7 @@ For example, if your cluster is running in the Ireland Region of Amazon Web
|
||||
Services (eu-west-1) and you configure three Swarm managers (1 x primary, 2 x
|
||||
secondary), you should place one in each availability zone as shown below.
|
||||
|
||||
|
||||
|
||||
|
||||
In this configuration, the Swarm cluster can survive the loss of any two
|
||||
availability zones. For your applications to survive such failures, they must be
|
||||
@@ -186,7 +186,7 @@ domains (availability zones). It also has Swarm nodes balanced across all three
|
||||
failure domains. The loss of two availability zones in the configuration shown
|
||||
below does not cause the Swarm cluster to go down.
|
||||
|
||||
|
||||
|
||||
|
||||
It is possible to share the same Consul, etcd, or Zookeeper containers between
|
||||
the Swarm discovery and Engine container networks. However, for best
|
||||
@@ -199,7 +199,7 @@ You can architect and build Swarm clusters that stretch across multiple cloud
|
||||
providers, and even across public cloud and on premises infrastructures. The
|
||||
diagram below shows an example Swarm cluster stretched across AWS and Azure.
|
||||
|
||||
|
||||
|
||||
|
||||
While such architectures may appear to provide the ultimate in availability,
|
||||
there are several factors to consider. Network latency can be problematic, as
|
||||
|
||||
@@ -79,7 +79,7 @@ This trust is usually established by way of a trusted third party. The Docker En
|
||||
CLI and Docker Engine daemon in the diagram below are configured to require TLS
|
||||
authentication.
|
||||
|
||||
|
||||
|
||||
|
||||
The trusted third party in this diagram is the Certificate Authority (CA)
|
||||
server. Like the country in the passport example, a CA creates, signs, issues,
|
||||
|
||||
@@ -28,7 +28,7 @@ web frontend that sends jobs to asynchronous background workers. The
|
||||
application's design can accommodate arbitrarily large scale. The diagram below
|
||||
shows the application's high level architecture:
|
||||
|
||||
|
||||
|
||||
|
||||
All the servers are running Docker Engine. The entire application is fully
|
||||
"Dockerized" in that all services are running inside of containers.
|
||||
@@ -59,7 +59,7 @@ between multiple containers across multiple Docker hosts.
|
||||
To support the application, the design calls for a Swarm cluster with a single
|
||||
Swarm manager and four nodes as shown below.
|
||||
|
||||
|
||||
|
||||
|
||||
All four nodes in the cluster are running the Docker daemon, as is the Swarm
|
||||
manager and the load balancer. The Swarm manager is part of the cluster and is
|
||||
@@ -71,7 +71,7 @@ demonstration it is not.
|
||||
After completing the example and deploying your application, this
|
||||
is what your environment should look like.
|
||||
|
||||
|
||||
|
||||
|
||||
As the previous diagram shows, each node in the cluster runs the following containers:
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@ starting a number of "Dockerized applications" running in containers.
|
||||
The diagram below shows the final application configuration including the overlay
|
||||
container network, `voteapp`.
|
||||
|
||||
|
||||
|
||||
|
||||
In this procedure you will connect containers to this network. The `voteapp`
|
||||
network is available to all Docker hosts using the Consul discovery backend.
|
||||
@@ -239,7 +239,7 @@ Now, you can test your application.
|
||||
|
||||
You should see something similar to the following:
|
||||
|
||||
|
||||
|
||||
|
||||
2. Click on one of the two voting options.
|
||||
3. Navigate to the `http://results.myenterprise.example.com` site to see the results.
|
||||
@@ -247,7 +247,7 @@ Now, you can test your application.
|
||||
|
||||
You'll see both sides change as you switch your vote.
|
||||
|
||||
|
||||
|
||||
|
||||
## Extra Credit: Deployment with Docker Compose
|
||||
|
||||
|
||||
@@ -188,7 +188,7 @@ To increase the availability of our Swarm cluster you could:
|
||||
|
||||
This configuration is shown in the diagram below.
|
||||
|
||||
|
||||
|
||||
|
||||
This will allow us to lose an entire AZ and still have our cluster and
|
||||
application operate.
|
||||
@@ -203,7 +203,7 @@ across AWS and Microsoft Azure. But you could just as easily replace one of
|
||||
those cloud providers with your own on premises data center. In these scenarios,
|
||||
network latency and reliability is key to a smooth and workable solution.
|
||||
|
||||
|
||||
|
||||
|
||||
## Related information
|
||||
|
||||
|
||||
Reference in New Issue
Block a user