Brandon Hunt
a78c3c7e8c
Two related style-conformance fixes across `content/guides/`, motivated by a recent audit of guide-page style against STYLE.md, COMPONENTS.md, and AGENTS.md. ## What changed ### 1. Add missing `keywords:` frontmatter to 104 guide pages `keywords` is documented as required (AGENTS.md, COMPONENTS.md) but was missing from 10 single-file guides, 8 `_index.md` landing pages, and 86 chapter pages. Each page now has a meaningful, page-specific comma-separated keyword list derived from its title, lead content, and sibling pages where applicable. Examples of the convention applied: - `content/guides/testcontainers-java-spring-boot-kafka/create-project.md` — `testcontainers, java, spring boot, kafka, mysql, project setup` - `content/guides/docker-compose/why.md` — `docker compose, multi-container, yaml, services, orchestration, application` Post-change verification confirms zero guide pages under `content/guides/` are missing the field. ### 2. Remove bold-for-emphasis from 14 guide pages STYLE.md restricts bold to UI elements only — never for emphasis, product names, command names, or the `**Term**: description` subsection-label pattern. Cleaned up the top-15 offender files identified by raw bold-span count (code blocks excluded). One file (`jupyter.md`, 32 spans) was untouched because all spans were legitimate UI references. Shape of the work across 14 files: - ~60 `**Term**: description` list items de-bolded - ~10 identifiers/values/commands converted to backticks (e.g. `**my-mysql**` → `` `my-mysql` ``) - ~10 product/emphasis bolds removed - 6 bolded link texts un-bolded - 3 blockquote-style notes converted to `> [!NOTE]` callouts Legitimate UI bolds (button names, menu items, field labels, tab names) were preserved throughout. `databases.md` kept 47 of 49 spans for this reason — only port-mapping value and container name were converted to backticks. ## Out of scope The audit surfaced other items not addressed here: - Series `params` block missing on all 48 `_index.md` landing pages — this is a "decide what's authoritative" question that warrants discussion before code changes. - Vale prose violations (`just`, `easily`, `we`, etc.) — concentrated in ~5 files; can land separately. - Heading numbering convention (`## Step N:` vs `## N.` vs plain) — undocumented; should be pinned down in STYLE.md or COMPONENTS.md before mechanical sweeps. ## Verification - `markdownlint` (via `scripts/lint.sh`) clean on all changed files. - Vale not installed locally; relying on CI to validate prose. - `git diff --stat` confirms scope: 118 unique files, all under `content/guides/`. No vendored, layout, or generated-file changes.
5.1 KiB
title, linkTitle, summary, description, keywords, tags, params
| title | linkTitle | summary | description | keywords | tags | params | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Faster development and testing with container-supported development | Container-supported dev | 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. | Use containers in your local development loop to develop and test faster… even if your main app isn't running in containers. | containers, local development, dependent services, testing, debugging, development environment |
|
|
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 >}}
Tip
Learn more about running databases in containers in the Use containerized databases guide.
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 >}}
Tip
Learn more about using WireMock to mock API in the Mocking API services with WireMock guide.
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 >}}
Tip
Learn more about using LocalStack in the Develop and test AWS Cloud applications using LocalStack guide.
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 >}}