Merge pull request #21129 from docker/published-update

publish updates from main

Author: dvdksn

assets/images/learning-paths/container-supported-development.png

@@ -0,0 +1,76 @@
+---
+title: "Faster development and testing with container-supported development"
+linkTitle: Container-supported development
+summary: |
+  Containers don't have to be just for your app. Learn how to run your app's dependent services and other debugging tools to enhance your development environment.
+description: |
+  Use containers in your local development loop to develop and test faster… even if your main app isn't running in containers.
+levels: [beginner]
+params:
+  image: images/learning-paths/container-supported-development.png
+  time: 20 minutes
+  resource_links: []
+---
+
+Containers offer a consistent way to build, share, and run applications across different environments. While containers are typically used to containerize your application, they also make it incredibly easy to run essential services needed for development. Instead of installing or connecting to a remote database, you can easily launch your own database. But the possibilities don't stop there.
+
+With container-supported development, you use containers to enhance your development environment by emulating or running your own instances of the services your app needs. This provides faster feedback loops, less coupling with remote services, and a greater ability to test error states.
+
+And best of all, you can have these benefits regardless of whether the main app under development is running in containers.
+
+## What you'll learn
+
+- The meaning of container-supported development
+- How to connect non-containerized applications to containerized services
+- Several examples of using containers to emulate or run local instances of services
+- How to use containers to add additional troubleshooting and debugging tools to your development environment
+
+## Who's this for?
+
+- Teams that want to reduce the coupling they have on shared or deployed infrastructure or remote API endpoints
+- Teams that want to reduce the complexity and costs associated with using cloud services directly during development
+- Developers that want to make it easier to visualize what's going on in their databases, queues, etc.
+- Teams that want to reduce the complexity of setting up their development environment without impacting the development of the app itself
+
+
+## Tools integration
+
+Works well with Docker Compose and Testcontainers.
+
+## Modules
+
+### What is container-supported development?
+
+Container-supported development is the idea of using containers to enhance your development environment by running local instances or emulators of the services your application relies on. Once you're using containers, it's easy to add additional services to visualize or troubleshoot what's going on in your services.
+
+{{< youtube-embed pNcrto_wGi0 >}}
+
+### Demo: running databases locally
+
+With container-supported development, it's easy to run databases locally. In this demo, you'll see how to do so, as well as how to connect a non-containerized application to the database.
+
+{{< youtube-embed VieWeXOwKLU >}}
+
+### Demo: mocking API endpoints
+
+Many APIs require data from other data endpoints. In development, this adds complexities such as the sharing of credentials, uptime/availability, and rate limiting. Instead of relying on those services directly, your application can interact with a mock API server.
+
+This demo will demonstrate how using WireMock can make it easy to develop and test an application, including the APIs various error states.
+
+{{< youtube-embed VXSmX6f8vo0 >}}
+
+### Demo: developing the cloud locally
+
+When developing apps, it's often easier to outsource aspects of the application to cloud services, such as Amazon S3. However, connecting to those services in local development introduces IAM policies, networking constraints, and provisioning complications. While these requirements are important in a production setting, they complicate development environments significantly. 
+
+With container-supported development, you can run local instances of these services during development and testing, removing the need for complex setups. In this demo, you'll see how LocalStack makes it easy to develop and test applications entirely from the developer's workstation.
+
+{{< youtube-embed JtwUMvR5xlY >}}
+
+### Demo: adding additional debug and troubleshooting tools
+
+Once you start using containers in your development environment, it becomes much easier to add additional containers to visualize the contents of the databases or message queues, seed document stores, or event publishers. In this demo, you'll see a few of these examples, as well as how you can connect multiple containers together to make testing even easier.
+
+{{< youtube-embed TCZX15aKSu4 >}}
+
+<div id="lp-survey-anchor"></div>

content/guides/container-supported-development.md

@@ -70,6 +70,16 @@ The builder has native support for the `linux/amd64` and `linux/arm64`
 architectures. This gives you a high-performance build cluster for building
 multi-platform images natively.
 
+## Firewall configuration
+
+To use Docker Build Cloud behind a firewall, ensure that your firewall allows
+traffic to the following addresses:
+
+- 3.211.38.21
+- https://auth.docker.io
+- https://build-cloud.docker.com
+- https://hub.docker.com
+
 ## What's next
 
 - See [Building with Docker Build Cloud](usage.md) for examples on how to use Docker Build Cloud.

content/manuals/build-cloud/setup.md

@@ -67,12 +67,12 @@ Logs will be available at the end of a job:
 
 You can provide a [BuildKit configuration](../../buildkit/toml-configuration.md)
 to your builder if you're using the [`docker-container` driver](/manuals/build/builders/drivers/docker-container.md)
-(default) with the `config` or `config-inline` inputs:
+(default) with the `config` or `buildkitd-config-inline` inputs:
 
 ### Registry mirror
 
 You can configure a registry mirror using an inline block directly in your
-workflow with the `config-inline` input:
+workflow with the `buildkitd-config-inline` input:
 
 ```yaml
 name: ci
@@ -87,7 +87,7 @@ jobs:
       - name: Set up Docker Buildx
         uses: docker/setup-buildx-action@v3
         with:
-          config-inline: |
+          buildkitd-config-inline: |
             [registry."docker.io"]
               mirrors = ["mirror.gcr.io"]
 ```
@@ -99,7 +99,7 @@ For more information about using a registry mirror, see [Registry mirror](../../
 You can limit the parallelism of the BuildKit solver which is particularly
 useful for low-powered machines.
 
-You can use the `config-inline` input like the previous example, or you can use
+You can use the `buildkitd-config-inline` input like the previous example, or you can use
 a dedicated BuildKit config file from your repository if you want with the
 `config` input:
 

content/manuals/build/ci/github-actions/configure-builder.md

@@ -89,8 +89,8 @@ $ docker completion zsh > ~/.docker/completions/_docker
 ```
 
 ```console
-$ cat <<EOT >> ~/.zshrc
-fpath=(~/.docker/completions \\$fpath)
+$ cat <<"EOT" >> ~/.zshrc
+FPATH="$HOME/.docker/completions:$FPATH"
 autoload -Uz compinit
 compinit
 EOT

content/manuals/engine/cli/completion.md

@@ -50,4 +50,4 @@ The following videos demonstrate how to enforce SSO.
 
 ## What's next
 
-Learn how you can [manage your SSO connection](../manage/_index.md), domain, and users for your organization or company.
+Learn how you can [manage your SSO connection](../single-sign-on/manage.md), domain, and users for your organization or company.

content/manuals/security/for-admins/single-sign-on/connect/_index.md renamed to content/manuals/security/for-admins/single-sign-on/connect.md

@@ -71,6 +71,6 @@ aliases:
 
 ## What's next?
 
-- [Set up SCIM](../../provisioning/scim.md)
-- [Enable Group mapping](../../provisioning/group-mapping.md)
+- [Set up SCIM](../provisioning/scim.md)
+- [Enable Group mapping](../provisioning/group-mapping.md)