mirror of
https://github.com/opentofu/opentofu.git
synced 2025-02-25 18:45:20 -06:00
Adds TACOS page to docs and links to it from all mentionds of TACOS (#1836)
Signed-off-by: Andrew Hayes <andrew.hayes@harness.io>
This commit is contained in:
parent
faf9f6aedc
commit
520165c089
@ -6,18 +6,18 @@ description: >-
|
||||
|
||||
# CLI Authentication
|
||||
|
||||
TACOS (TF Automation and Collaboration Software) are platforms that perform as part of their
|
||||
[TACOS](../../intro/tacos.mdx) (TF Automation and Collaboration Software) are platforms that perform as part of their
|
||||
offering OpenTofu runs to provision infrastructure, offering a collaboration-focused
|
||||
environment that makes it easier for teams to use OpenTofu together.
|
||||
|
||||
OpenTofu CLI integrates with TACOS in several ways — it can be a
|
||||
front-end for CLI-driven runs, and can also use some TACOS as a state backend, a private module
|
||||
OpenTofu CLI integrates with [TACOS](../../intro/tacos.mdx) in several ways — it can be a
|
||||
front-end for CLI-driven runs, and can also use some [TACOS](../../intro/tacos.mdx) as a state backend, a private module
|
||||
registry, or a private provider registry. All of these integrations require you to authenticate OpenTofu CLI
|
||||
with your TACOS account.
|
||||
with your [TACOS](../../intro/tacos.mdx) account.
|
||||
|
||||
The best way to handle CLI authentication is with the `login` and `logout`
|
||||
commands, which help automate the process of getting an API token for your
|
||||
TACOS user account.
|
||||
[TACOS](../../intro/tacos.mdx) user account.
|
||||
|
||||
For details, see:
|
||||
|
||||
|
@ -11,7 +11,7 @@ description: >-
|
||||
This is the documentation for OpenTofu CLI. It is relevant to anyone working
|
||||
with OpenTofu's CLI-based workflows; this includes people who use OpenTofu CLI
|
||||
by itself, as well as those who use OpenTofu CLI in conjunction with
|
||||
TACOS (TF Automation and Collaboration Software).
|
||||
[TACOS](../intro/tacos.mdx) (TF Automation and Collaboration Software).
|
||||
|
||||
Notably, this documentation does not cover the syntax and usage of the OpenTofu
|
||||
language. For that, see the
|
||||
|
@ -217,5 +217,5 @@ There are many different ways to use OpenTofu: as an individual user, a single
|
||||
team, or an entire organization at scale. Choosing the best approach for the
|
||||
density of collaboration needed will provide the most return on your investment
|
||||
in the core OpenTofu workflow. For organizations using OpenTofu at scale,
|
||||
TACOS (TF Automation and Collaboration Software) introduces new layers that build on this core workflow to
|
||||
[TACOS](../intro/tacos.mdx) (TF Automation and Collaboration Software) introduces new layers that build on this core workflow to
|
||||
solve problems unique to teams and organizations.
|
||||
|
17
website/docs/intro/tacos.mdx
Normal file
17
website/docs/intro/tacos.mdx
Normal file
@ -0,0 +1,17 @@
|
||||
---
|
||||
sidebar_position: 7
|
||||
sidebar_label: What are TACOS?
|
||||
description: |-
|
||||
Learn all about TACOS.
|
||||
---
|
||||
|
||||
# What are TACOS?
|
||||
|
||||
TF Automation and Collaboration Software (TACOS) are platforms which allow teams to manage and orchestrate OpenTofu execution. They offer a wide variety of services to provide a streamlined and collaborative experience.
|
||||
|
||||
# What are some examples?
|
||||
|
||||
There are a variety of platforms which offer OpenTofu support, both Open Source and Commercial. Many of these organizations support OpenTofu directly and can be found on our [supporters](../../../supporters) page.
|
||||
|
||||
|
||||
|
@ -68,7 +68,7 @@ Check blocks do not currently support [meta-arguments](../../language/resources/
|
||||
|
||||
## Continuous validation in TACOS (TF Automation and Collaboration Software)
|
||||
|
||||
TACOS (TF Automation and Collaboration Software) can automatically validate whether checks in a workspace’s configuration continue to pass after OpenTofu provisions new infrastructure.
|
||||
[TACOS](../../intro/tacos.mdx) (TF Automation and Collaboration Software) can automatically validate whether checks in a workspace’s configuration continue to pass after OpenTofu provisions new infrastructure.
|
||||
|
||||
## Choosing Checks or other Custom Conditions
|
||||
|
||||
|
@ -64,7 +64,7 @@ called by those modules, etc.).
|
||||
- In OpenTofu CLI, the root module is the working directory where OpenTofu is
|
||||
invoked. (You can use command line options to specify a root module outside
|
||||
the working directory, but in practice this is rare.)
|
||||
- In TACOS (TF Automation and Collaboration Software), the root module for a workspace
|
||||
- In [TACOS](../../intro/tacos.mdx) (TF Automation and Collaboration Software), the root module for a workspace
|
||||
defaults to the top level of the configuration directory (supplied via version
|
||||
control repository or direct upload), but the workspace settings can specify a
|
||||
subdirectory to use instead.
|
||||
|
@ -8,7 +8,7 @@ description: >-
|
||||
# OpenTofu Language Documentation
|
||||
|
||||
This is the documentation for OpenTofu's configuration language. It is relevant
|
||||
to users of [OpenTofu CLI](../cli/index.mdx), and TACOS (TF Automation and Collaboration Software).
|
||||
to users of [OpenTofu CLI](../cli/index.mdx), and [TACOS](../intro/tacos.mdx) (TF Automation and Collaboration Software).
|
||||
OpenTofu's language is its primary user interface. Configuration files you write in OpenTofu
|
||||
language tell OpenTofu what plugins to install, what infrastructure to create,
|
||||
and what data to fetch. OpenTofu language also lets you define dependencies
|
||||
|
@ -41,7 +41,7 @@ download them automatically if you specify the appropriate source and version in
|
||||
a module call block.
|
||||
|
||||
Also, members of your organization might produce modules specifically crafted
|
||||
for your own infrastructure needs. TACOS (TF Automation and Collaboration Software) include a private
|
||||
for your own infrastructure needs. [TACOS](../../intro/tacos.mdx) (TF Automation and Collaboration Software) include a private
|
||||
module registry for sharing modules internally within your organization.
|
||||
|
||||
## Using Modules
|
||||
|
@ -95,7 +95,7 @@ community.
|
||||
|
||||
You can also use a
|
||||
[private registry](../../internals/module-registry-protocol.mdx), either
|
||||
via TACOS (TF Automation and Collaboration Software), or by running a custom
|
||||
via [TACOS](../../../intro/tacos.mdx) (TF Automation and Collaboration Software), or by running a custom
|
||||
service that implements
|
||||
[the module registry protocol](../../internals/module-registry-protocol.mdx).
|
||||
|
||||
@ -135,7 +135,7 @@ You can learn more about the registry at the
|
||||
To access modules from a private registry, you may need to configure an access
|
||||
token [in the CLI config](../../cli/config/config-file.mdx#credentials). Use the
|
||||
same hostname as used in the module source string. For a private registry
|
||||
within TACOS (TF Automation and Collaboration Software), use the same authentication token as you would
|
||||
within [TACOS](../../../intro/tacos.mdx) (TF Automation and Collaboration Software), use the same authentication token as you would
|
||||
use with the API or command-line clients.
|
||||
|
||||
## GitHub
|
||||
|
@ -98,7 +98,7 @@ version that meets the constraint.
|
||||
|
||||
Version constraints are supported only for modules installed from a module
|
||||
registry, such as the [Public OpenTofu Registry](https://registry.opentofu.org/)
|
||||
or any TACOS (TF Automation and Collaboration Software) private modules registry.
|
||||
or any [TACOS](../../../intro/tacos.mdx) (TF Automation and Collaboration Software) private modules registry.
|
||||
Other module sources can provide their own versioning mechanisms within the
|
||||
source string itself, or might not support versions at all. In particular,
|
||||
modules sourced from local file paths do not support `version`; since
|
||||
|
@ -63,7 +63,7 @@ about it in your configuration. See the following pages for details:
|
||||
|
||||
## Provider Installation
|
||||
|
||||
- TACOS (TF Automation and Collaboration Software) install providers as part of every run.
|
||||
- [TACOS](../../intro/tacos.mdx) (TF Automation and Collaboration Software) install providers as part of every run.
|
||||
|
||||
- OpenTofu CLI finds and installs providers when
|
||||
[initializing a working directory](../../cli/init/index.mdx). It can
|
||||
@ -79,7 +79,7 @@ To ensure OpenTofu always installs the same provider versions for a given
|
||||
configuration, you can use OpenTofu CLI to create a
|
||||
[dependency lock file](../../language/files/dependency-lock.mdx)
|
||||
and commit it to version control along with your configuration. If a lock file
|
||||
is present, OpenTofu CLI, and TACOS (TF Automation and Collaboration Software) will all obey it when
|
||||
is present, OpenTofu CLI, and [TACOS](../../intro/tacos.mdx) (TF Automation and Collaboration Software) will all obey it when
|
||||
installing providers.
|
||||
|
||||
## How to Find Providers
|
||||
|
@ -203,7 +203,7 @@ To ensure OpenTofu always installs the same provider versions for a given
|
||||
configuration, you can use OpenTofu CLI to create a
|
||||
[dependency lock file](../../language/files/dependency-lock.mdx)
|
||||
and commit it to version control along with your configuration. If a lock file
|
||||
is present, OpenTofu CLI, and TACOS (TF Automation and Collaboration Software) will all obey it when
|
||||
is present, OpenTofu CLI, and [TACOS](../../intro/tacos.mdx) (TF Automation and Collaboration Software) will all obey it when
|
||||
installing providers.
|
||||
|
||||
### Best Practices for Provider Versions
|
||||
|
@ -8,7 +8,7 @@ description: >-
|
||||
|
||||
A backend defines where OpenTofu stores its [state](../../../language/state/index.mdx) data files.
|
||||
|
||||
OpenTofu uses persisted state data to keep track of the resources it manages. Most non-trivial OpenTofu configurations either integrate with TACOS (TF Automation and Collaboration Software) or use a backend to store state remotely. This lets multiple people access the state data and work together on that collection of infrastructure resources.
|
||||
OpenTofu uses persisted state data to keep track of the resources it manages. Most non-trivial OpenTofu configurations either integrate with [TACOS](../../../intro/tacos.mdx) (TF Automation and Collaboration Software) or use a backend to store state remotely. This lets multiple people access the state data and work together on that collection of infrastructure resources.
|
||||
|
||||
This page describes how to configure a backend by adding the [`backend` block](#using-a-backend-block) to your configuration.
|
||||
|
||||
@ -20,7 +20,7 @@ Some of these backends act like plain remote disks for state files, while others
|
||||
|
||||
## Using a Backend Block
|
||||
|
||||
You do not need to configure a backend when using TACOS (TF Automation and Collaboration Software) because
|
||||
You do not need to configure a backend when using [TACOS](../../../intro/tacos.mdx) (TF Automation and Collaboration Software) because
|
||||
it automatically manages state in the workspaces associated with your configuration. If your configuration includes a [`cloud` block](../../../language/settings/tf-cloud.mdx), it cannot include a `backend` block.
|
||||
|
||||
To configure a backend, add a nested `backend` block within the top-level
|
||||
|
@ -11,16 +11,16 @@ description: >-
|
||||
**We recommend using the [`cloud` built-in integration](../../../cli/cloud/settings.mdx)** instead of this backend. The `cloud` option includes an improved user experience and more features.
|
||||
:::
|
||||
|
||||
The remote backend is unique among all other OpenTofu backends because it can both store state snapshots and execute CLI-driven run workflow operations for TF Automation and Collaboration Software (TACOS) backends. It used to be called an "enhanced" backend.
|
||||
The remote backend is unique among all other OpenTofu backends because it can both store state snapshots and execute CLI-driven run workflow operations for TF Automation and Collaboration Software ([TACOS](../../../intro/tacos.mdx)) backends. It used to be called an "enhanced" backend.
|
||||
|
||||
If your TACOS provider enables full remote operations, you can execute commands such as `tofu plan` or `tofu apply` within the TACOS runtime environment, with log output streaming directly to your local terminal. Remote plans and applies use variable values from the associated remote workspace.
|
||||
If your [TACOS](../../../intro/tacos.mdx) provider enables full remote operations, you can execute commands such as `tofu plan` or `tofu apply` within the [TACOS](../../../intro/tacos.mdx) runtime environment, with log output streaming directly to your local terminal. Remote plans and applies use variable values from the associated remote workspace.
|
||||
|
||||
You can also use TACOS with local operations, where only state is stored in the TACOS remote backend.
|
||||
You can also use [TACOS](../../../intro/tacos.mdx) with local operations, where only state is stored in the [TACOS](../../../intro/tacos.mdx) remote backend.
|
||||
|
||||
## Command Support
|
||||
|
||||
:::note
|
||||
Features implementation might vary between different TACOS.
|
||||
Features implementation might vary between different [TACOS](../../../intro/tacos.mdx).
|
||||
:::
|
||||
|
||||
The remote backend supports the following OpenTofu commands:
|
||||
@ -66,7 +66,7 @@ setting both results in a configuration error.
|
||||
If previous state is present when you run `tofu init` and the corresponding
|
||||
remote workspaces are empty or absent, OpenTofu will create workspaces and
|
||||
update the remote state accordingly. However, if your workspace requires variables or a specific version of OpenTofu for remote operations, we
|
||||
recommend that you create your remote workspaces on TACOS before
|
||||
recommend that you create your remote workspaces on [TACOS](../../../intro/tacos.mdx) before
|
||||
running any remote operations against them.
|
||||
|
||||
### Workspace Names
|
||||
@ -179,7 +179,7 @@ The following configuration options are supported:
|
||||
only the default workspace can be used. This option conflicts with `prefix`.
|
||||
- `prefix` - (Optional) A prefix used in the names of one or more remote
|
||||
workspaces, all of which can be used with this configuration. The full
|
||||
workspace names are used in TACOS, and the short names
|
||||
workspace names are used in [TACOS](../../../intro/tacos.mdx), and the short names
|
||||
(minus the prefix) are used on the command line for OpenTofu CLI workspaces.
|
||||
If omitted, only the default workspace can be used. This option conflicts with `name`.
|
||||
|
||||
@ -212,7 +212,7 @@ the remote workspace accept the following option to modify that behavior:
|
||||
## Excluding Files from Upload with .terraformignore
|
||||
|
||||
When executing a remote `plan` or `apply` in a CLI-driven run,
|
||||
an archive of your configuration directory is uploaded to TACOS. You can define
|
||||
an archive of your configuration directory is uploaded to [TACOS](../../../intro/tacos.mdx). You can define
|
||||
paths to ignore from upload via a `.terraformignore` file at the root of your configuration directory. If this file is not present, the archive will exclude the following by default:
|
||||
|
||||
- `.git/` directories
|
||||
|
@ -12,7 +12,7 @@ resources to your configuration, keep track of metadata, and to improve
|
||||
performance for large infrastructures.
|
||||
|
||||
This state is stored by default in a local file named "terraform.tfstate",
|
||||
but we recommend storing it in TACOS (TF Automation and Collaboration Software)
|
||||
but we recommend storing it in [TACOS](../../intro/tacos.mdx) (TF Automation and Collaboration Software)
|
||||
to version, encrypt, and securely share it with your team.
|
||||
|
||||
OpenTofu uses state to determine which changes to make to your
|
||||
|
@ -14,11 +14,11 @@ OpenTofu at the same time.
|
||||
|
||||
With _remote_ state, OpenTofu writes the state data to a remote data store,
|
||||
which can then be shared between all members of a team. OpenTofu supports
|
||||
storing state in TACOS (TF Automation and Collaboration Software),
|
||||
storing state in [TACOS](../../intro/tacos.mdx) (TF Automation and Collaboration Software),
|
||||
[HashiCorp Consul](https://www.consul.io/), Amazon S3, Azure Blob Storage, Google Cloud Storage, Alibaba Cloud OSS, and more.
|
||||
|
||||
Remote state is implemented by a [backend](../../language/settings/backends/configuration.mdx) or by
|
||||
TACOS (TF Automation and Collaboration Software), both of which you can configure in your configuration's root module.
|
||||
[TACOS](../../intro/tacos.mdx) (TF Automation and Collaboration Software), both of which you can configure in your configuration's root module.
|
||||
|
||||
## Delegation and Teamwork
|
||||
|
||||
@ -54,7 +54,7 @@ For fully-featured remote backends, OpenTofu can also use
|
||||
[state locking](../../language/state/locking.mdx) to prevent concurrent runs of
|
||||
OpenTofu against the same state.
|
||||
|
||||
TACOS (TF Automation and Collaboration Software) is a commercial offering
|
||||
[TACOS](../../intro/tacos.mdx) (TF Automation and Collaboration Software) is a commercial offering
|
||||
that supports an even stronger locking concept that
|
||||
can also detect attempts to create a new plan when an existing plan is already
|
||||
awaiting approval, by queuing OpenTofu operations in a central location.
|
||||
|
Loading…
Reference in New Issue
Block a user