diff --git a/content/en/docs/concepts/_index.md b/content/en/docs/concepts/_index.md deleted file mode 100644 index f4d7a898..00000000 --- a/content/en/docs/concepts/_index.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: "Concepts" -linkTitle: "Concepts" -weight: 4 -description: > - This section covers some concepts that are important to understand for day to day Score usage and operation. ---- - -This section is recommended reading for anyone consuming or operating Score. - -Use the navigation menu or the items listed below to learn more about a topic. diff --git a/content/en/docs/concepts/configuration-management.md b/content/en/docs/concepts/configuration-management.md deleted file mode 100644 index 593e3cd9..00000000 --- a/content/en/docs/concepts/configuration-management.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Configuration management" -linkTitle: "Configuration management" -weight: 4 -draft: true -description: > - _Configuration management_, also known as configuration drift, is the difference between how your environments are defined. ---- - -_Configuration management_, also known as configuration drift, is the difference between how your environments are defined. - -In modern software development, applications are typically deployed as microservices, each part is packaged into its own container and promoted across different cloud environments. To run containerized Workloads, teams make use of container orchestration platforms. As a developer, you might be using Docker Compose or Minikube for local development and deploy to remote environments that are based on systems such as Kubernetes, OpenShift, Nomad, or AWS ECS. - -To successfully develop, test, deploy, and run a Workload, you should not only have to be familiar with the platform and related tooling your team makes use of, but also keep each Workload's specification in sync. If entities are configured differently across platforms, the risk of configuration mismanagement increases. - -For example, a Workload with a dependency on a database might point to a Postgres image or mock server in lower environments. On its way to production: however, a database has to be provisioned and allocated by Terraform. Such _translation gaps_ between environments exist for all kinds of items - volumes, external services (for example Vault or RabbitMQ), ports, DNS records, or routes. - -From a developer’s point of view, you successfully test and run a Workload locally, through docker compose, and even pass the isolated tests embedded into your CI pipeline. The question of how things are now appropriately reflected in the next environment, which might be running on Kubernetes and is managed through Helm `values.yaml` file - is answered differently in every team and depends on the complexity of the task at hand. A variable change is easier to keep in sync than declaring a dependency on a database across different platforms. - -In practice, an Ops Engineer might jump in to review configuration changes. You might compare the Workload specification for each platform yourself. A colleague might be working on a policy definition for YAML files. Either way, if a property is overseen or has accidentally been wrongly specified, the team will end up with a failed deployment or a Workload that is running in a way that it’s not intended to. diff --git a/content/en/docs/concepts/container.md b/content/en/docs/concepts/container.md deleted file mode 100644 index a8c1da4a..00000000 --- a/content/en/docs/concepts/container.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: "Container" -linkTitle: "Container" -weight: 4 -description: > - A _container_ is a ready-to-run software package that bundles up an application’s code together with any runtime it requires: system tools, libraries, and default values for any essential settings. ---- - -A _container_ is a ready-to-run software package that bundles up an application’s code together with any runtime it requires: system tools, libraries, and default values for any essential settings. - -Containers are created from read-only templates called an _image_. Images are immutable by design. If the application code or default configuration changes, a new container image must be built. diff --git a/content/en/docs/concepts/dependencies.md b/content/en/docs/concepts/dependencies.md deleted file mode 100644 index 7b697c94..00000000 --- a/content/en/docs/concepts/dependencies.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: "Dependencies" -linkTitle: "Dependencies" -weight: 4 -description: > - The Score Specification can define one or more dependencies required by the Workload to run. ---- - -The Score Specification can define one or more dependencies required by the Workload to run. -This could include other Workloads, third-party services, configurations, or resources such as databases and volumes. - -Workload dependencies are described in a declarative way. - -The Score Specification doesn't define how to configure or provision any dependencies but may include additional metadata (name, type, or labels) that allows the Score implementation (CLI) to identify and link it to the platform that consumes the output file generated based on `score.yaml` to deploy the Workload at runtime. - -For example, a Workload with a dependency on a database might point to a Postgres image or mock server in lower environments. On its way to production; however, a database has to be provisioned and allocated by Terraform. diff --git a/content/en/docs/concepts/environment-configuration.md b/content/en/docs/concepts/environment-configuration.md deleted file mode 100644 index 5e67e880..00000000 --- a/content/en/docs/concepts/environment-configuration.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Environment-specific configuration" -linkTitle: "Environment-specific configuration" -weight: 4 -description: Pass environment-specific configurations to the Workload during a deployment. ---- - -Environment-specific configuration is configuration that is expected to vary between environments. For example, a production Workload that uses a managed service like Twilio might use a production API key to access the service. In the dev environment, a development API key might be used to avoid incurring cost with test traffic. We would not be surprised to see different API keys in different environments. - -## Overview - -The Score Specification is defined in an environment-agnostic way, meaning it can be combined with environment-specific values to run Workloads in the target environment. For example: Your Score spec might specify a parameterized database connection string such as `postgres://${postgres.username}:postgres.password}@${postgres.host}:${postgres.port}/${postgres.name}` which is resolved in each environment the Workload is deployed to, by injecting the according credentials. - -### Use case - -Score supports dynamic configuration management. For example: - -1. The Score Spec declares that a Workload is available on a TCP port. -1. The configuration value is then sourced from the target's environment application settings. -1. The Score Spec declares that the Workload is deployed in multiple replicas so that the application can scale up. - 1. The exact number of replicas can differ given the environment. -1. The environment-specific variables include a value for each of the environments. -1. The Score Spec declares a container image, `name` and `tag`. - 1. The image pulls a `secret` to fetch the image from that registry, which is made available by the platform. - -For implementation details, see [Environment variables for Score Specification]({{< relref "/docs/environment%20variables/_index.md" >}} "Environment variables"). diff --git a/content/en/docs/concepts/score.md b/content/en/docs/concepts/score.md deleted file mode 100644 index 04623831..00000000 --- a/content/en/docs/concepts/score.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: "Score" -linkTitle: "Score" -weight: 4 -description: > - Score is made up of two components, the Score Specification file and the Score implementation CLI tool. ---- - -## Score Specification - -The Score Specification is a developer-centric definition that describes how to run a Workload. As a platform-agnostic declaration file, `score.yaml` file presents the single source of truth on a Workloads profile of requirements and works to utilize any platform or tooling. - -With the Score Specification, the same Workload can be run on entirely different technology stacks without the developer needing to be an expert in any of them. For example, the same Score Specification can be used to generate a Docker-Compose file for local development, Kubernetes manifests for deployment to a shared development environment and to a serverless platform such as Google Cloud Run for integration tests. - -## Score implementation CLI - -A Score Implementation CLI is used to run against the Score Specification file. It is tied to a platform such as Docker Compose (`score-compose`) or Helm (`score-helm`) and will take care of converting the Score Specification into the required platform-specific configuration file such as `docker-compose.yaml`, `values.yaml` and can be combined with environment-specific parameters to run the Workload in the target environment. diff --git a/content/en/docs/concepts/workload.md b/content/en/docs/concepts/workload.md deleted file mode 100644 index 5680f80e..00000000 --- a/content/en/docs/concepts/workload.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: "Workload" -linkTitle: "Workload" -weight: 4 -description: > - A _Workload_ is a deployable application made up of one or more containers that runs in the same context and share resources, dependencies and networks. ---- - -The Workload is a specification of how the containers should be run. -For example, it might be run as a long-lived process, such as a microservice or application, or short-lived on demand, such as a cron job. -You may prefer to think of Workloads as applications, programs, or processes if compared to non-cloud setups that run on a host or a virtual machine. diff --git a/content/en/docs/dependencies/_index.md b/content/en/docs/dependencies/_index.md index b06f5d66..66cdd4c3 100644 --- a/content/en/docs/dependencies/_index.md +++ b/content/en/docs/dependencies/_index.md @@ -4,6 +4,8 @@ linkTitle: "Declare dependencies" weight: 6 description: > Describes how to set Workloads that are dependent on additional resources. +aliases: +- /docs/concepts/dependencies --- The Score Specification has a `resources` section that is used to describe Workload's dependencies. This mechanism can be used to spin-up multiservice setups. @@ -157,5 +159,4 @@ compose-service-b-1 | service-b: Hello World! For more information, see the following links. -- Review the [Workload dependencies]({{< relref "../concepts/dependencies" >}} "Workload dependencies") page. -- Review the [resource section]({{< relref "../reference/score-spec-reference.md#resources-definition" >}} "Resource definition") of the Score Specification reference. +- Review the [resource section]({{< relref "/docs/reference/score-spec-reference.md#resources-definition" >}} "Resource definition") of the Score Specification reference. diff --git a/content/en/docs/environment variables/_index.md b/content/en/docs/environment variables/_index.md index 46e8f9f1..83633ad0 100644 --- a/content/en/docs/environment variables/_index.md +++ b/content/en/docs/environment variables/_index.md @@ -10,10 +10,14 @@ description: > You can pass environment-specific configuration to the container during a deployment. The Score Specification enables a special environment resource type to be used to support such use cases. -Environment configurations are set within the [`resource`]({{< relref "../reference/score-spec-reference.md" >}} "Container") section of your Score Specification file. These act as environment variables when you're deploying a {{< glossary_tooltip text="Workload" term_id="workload" >}}. +Environment configurations are set within the [`resource`]({{< relref "/docs/reference/score-spec-reference.md" >}} "Container") section of your Score Specification file. These act as environment variables when you're deploying a Workload. Values for those variables can be either hard-coded (not recommended) or sourced from the resources properties through substitutions (recommended) such as `${resources.my-db.host}`. The Score Specification supports declaring environment variables in a configurations files or as a shell value. -For more information, see [Environment specific configuration]({{< relref "../concepts/environment-configuration" >}}) +For more information, see + +- [Environment variables in score-compose]({{< relref "/docs/environment variables/environment-variables-compose" >}}) +- [Environment variables in score-helm]({{< relref "/docs/environment variables/environment-variables-helm" >}}) +- [Environment variables in score-humanite]({{< relref "/docs/environment variables/environment-variables-humanitec" >}}) \ No newline at end of file diff --git a/content/en/docs/environment variables/environment-variables-helm.md b/content/en/docs/environment variables/environment-variables-helm.md index e63d70a0..d559d6c1 100644 --- a/content/en/docs/environment variables/environment-variables-helm.md +++ b/content/en/docs/environment variables/environment-variables-helm.md @@ -38,7 +38,7 @@ resources: > Resources need to map to the resource structure. > To declare environment variables in a Score file, the variable name, `resources.env.NAME` must map to the structure in `resource` section. -For more information, see the [Resource section]({{< relref "/content/en/docs/reference/score-spec-reference.md#referencing-resources" >}}) in the Score Specification reference. +For more information, see the [Resource section]({{< relref "/docs/reference/score-spec-reference.md#referencing-resources" >}}) in the Score Specification reference. {{% /alert %}} diff --git a/content/en/docs/environment variables/environment-variables-humanitec.md b/content/en/docs/environment variables/environment-variables-humanitec.md index ed21877d..6d437f54 100644 --- a/content/en/docs/environment variables/environment-variables-humanitec.md +++ b/content/en/docs/environment variables/environment-variables-humanitec.md @@ -36,7 +36,7 @@ resources: > Resources need to map to the resource structure. > To declare environment variables in a Score file, the variable name, `resources.env.NAME` must map to the structure in `resource` section. -For more information, see the [Resource section]({{< relref "/content/en/docs/reference/score-spec-reference.md#referencing-resources" >}}) in the Score Specification reference. +For more information, see the [Resource section]({{< relref "/docs/reference/score-spec-reference.md#referencing-resources" >}}) in the Score Specification reference. {{% /alert %}} diff --git a/content/en/docs/extensions/_index.md b/content/en/docs/extensions/_index.md index cf0ff269..4cbc82c0 100644 --- a/content/en/docs/extensions/_index.md +++ b/content/en/docs/extensions/_index.md @@ -22,7 +22,7 @@ Score supports extension files. -Applications that consist of multiple microservices typically need a routing controller that redirects incoming requests to a proper {{< glossary_tooltip text="Workload" term_id="workload" >}} at run time. +Applications that consist of multiple microservices typically need a routing controller that redirects incoming requests to a proper Workload at run time. For example, a common scenario is to deploy an API Gateway, Ingress controller, or Service mesh as part of your application. Maintaining and updating routing tables after new service deployments is a point of friction as the application scales. @@ -35,9 +35,9 @@ Routes convert into resource definitions, so proper routes can be provisioned at {{% alert %}} -> The Score Specification file has a concept of a {{< glossary_tooltip text="Workload specification" term_id="workload-spec" >}} that defines the requirements to run a Workload, but isn't used to manage Target Configuration or to provision any of the dependencies. +> The Score Specification file has a concept of a Workload specification that defines the requirements to run a Workload, but isn't used to manage Target Configuration or to provision any of the dependencies. -For more information, see [Score Specification]({{< relref "../concepts/score.md" >}} "Score Specification"). +For more information, see [Score Specification]({{< relref "/docs/reference/score-spec-reference" >}} "Score Specification"). {{% /alert %}} diff --git a/content/en/docs/extensions/implement-ports-volumes.md b/content/en/docs/extensions/implement-ports-volumes.md index aae0f984..53567a17 100644 --- a/content/en/docs/extensions/implement-ports-volumes.md +++ b/content/en/docs/extensions/implement-ports-volumes.md @@ -5,7 +5,7 @@ weight: 4 draft: false --- -Using files and volumes or serving incoming requests on selected ports helps to build real world {{< glossary_tooltip text="Workloads" term_id="workload" >}} and applications. +Using files and volumes or serving incoming requests on selected ports helps to build real world Workloads and applications. In such a scenario, you'd want to express this in your `score.yaml` file. @@ -38,7 +38,7 @@ resources: Paired with the `score.yaml` file is the extension file, `humanitec.score.yaml`, which contains additional hints for the score-humanitec CLI tool. -The extension file helps the CLI tool add proper routes to Humanitec's {{< glossary_tooltip text="Deployment Delta" term_id="deployment-delta" >}}, so that the service is available to the outer world. +The extension file helps the CLI tool add proper routes to Humanitec's Deployment Delta, so that the service is available to the outer world. The following is an implementation of the `humanitec.score.yaml` file. @@ -127,4 +127,4 @@ The generated JSON can then be used as a payload for a [Humanitec API call](http When deploying this service with `Humanitec`, make sure that the shared application value called `MESSAGE` is set for the target environment. -For more information, see the [Humanitec extension reference]({{< relref "/content/en/docs/reference/humanitec-extension.md" >}}). +For more information, see the [Humanitec extension reference]({{< relref "/docs/reference/humanitec-extension.md" >}}). diff --git a/content/en/docs/get started/_index.md b/content/en/docs/get started/_index.md index 3e5e29e3..57996a6a 100644 --- a/content/en/docs/get started/_index.md +++ b/content/en/docs/get started/_index.md @@ -6,4 +6,4 @@ weight: 2 ## Overview -The primary goal of the Score file is to quickly and easily describe a {{< glossary_tooltip text="Workloads" term_id="workload" >}} runtime requirements. The following covers what you need to know to compose a Score file and run a Workload via a Score Implementation CLI. +The primary goal of the Score file is to quickly and easily describe a Workloads's runtime requirements. The following covers what you need to know to compose a Score file and run a Workload via a Score Implementation CLI. diff --git a/content/en/docs/get started/install.md b/content/en/docs/get started/install.md index 722105ec..46630eed 100644 --- a/content/en/docs/get started/install.md +++ b/content/en/docs/get started/install.md @@ -100,7 +100,7 @@ To upgrade the Score implementation (CLI), download the latest binary version an - -Those values may change based on the target environment, like `testing`, `integration`, or `production` - -For example, route table management is a configuration management task and Score isn't a configuration management tool. diff --git a/content/en/docs/glossary/configuration-management.md b/content/en/docs/glossary/configuration-management.md deleted file mode 100644 index 29675e40..00000000 --- a/content/en/docs/glossary/configuration-management.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: Configuration management -id: config-drift -full_link: /docs/concepts/score/ -short_description: > - Configuration management is the difference between how your local environment and remote environments are defined. -tags: -- core -- score ---- - - - -Configuration management is the difference between how your local environment and remote environments are defined. diff --git a/content/en/docs/glossary/deployment-delta.md b/content/en/docs/glossary/deployment-delta.md deleted file mode 100644 index b5db53f5..00000000 --- a/content/en/docs/glossary/deployment-delta.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: Deployment Delta -id: deployment-delta -full_link: /docs/concepts/score/ -short_description: > - A Deployment Delta describes the changes that must be applied to one Deployment Set to generate another Deployment Set. -tags: -- core -- score ---- - -A Deployment Delta describes the changes that must be applied to one Deployment Set to generate another Deployment Set. Deployment Deltas are the only way to create new Deployment Sets. - - - -Deployment Deltas can be created fully formed or combined through a `PATCH` method. They can also be generated from the difference between two Deployment Sets. diff --git a/content/en/docs/glossary/environment-variables.md b/content/en/docs/glossary/environment-variables.md deleted file mode 100644 index b5f5d29a..00000000 --- a/content/en/docs/glossary/environment-variables.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: Environment variables -id: environment-var -full_link: /docs/concepts/environment-configuration/ -short_description: > - Environment-specific configuration allows the Score Specification file to be combined with variables to run Workloads in the target environment. -tags: -- core -- fundamental ---- - -Environment-specific configuration allows the Score Specification file to be combined with variables to run Workloads in the target environment. diff --git a/content/en/docs/glossary/environment.md b/content/en/docs/glossary/environment.md deleted file mode 100644 index 28947a82..00000000 --- a/content/en/docs/glossary/environment.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: Environment -id: environment -full_link: /docs/concepts/environment-configuration/ -short_description: > - An Environment is a space where an instance of an Application can be deployed. It consists of a Kubernetes namespace and any shared Resources (as configured by relevant matching criteria). -tags: -- core -- fundamental ---- - -An Environment is a space where an instance of an Application can be deployed. It consists of a Kubernetes namespace and any shared Resources (as configured by relevant matching criteria). diff --git a/content/en/docs/glossary/index.md b/content/en/docs/glossary/index.md index b9a780b0..69240b26 100644 --- a/content/en/docs/glossary/index.md +++ b/content/en/docs/glossary/index.md @@ -3,10 +3,11 @@ title: Glossary layout: glossary filter_text: Filter tags noedit: true +draft: true weight: 10 hide_summary: true card: name: reference weight: 10 title: Glossary ---- +--- \ No newline at end of file diff --git a/content/en/docs/glossary/resource.md b/content/en/docs/glossary/resource.md deleted file mode 100644 index f614853b..00000000 --- a/content/en/docs/glossary/resource.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: Resource -id: resource -full_link: /docs/concepts/dependencies/ -short_description: > - The `resource` section describes a Workload's dependencies. -tags: -- workload -- fundamental ---- - -The `resource` section describes a Workload's dependencies. - - - -This mechanism can be used to spin-up multi-service setups with `docker compose`. diff --git a/content/en/docs/glossary/score-specification.md b/content/en/docs/glossary/score-specification.md deleted file mode 100644 index e5190b13..00000000 --- a/content/en/docs/glossary/score-specification.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: Score Specification -id: score-spec -full_link: /docs/concepts/score/ -short_description: > - The _Score Specification_ provides a developer-centric and platform-agnostic Workload specification to improve developer productivity and experience. It eliminates configuration mismanagement between environments. -tags: -- score -- fundamental -- extension ---- - -The _Score Specification_ provides a developer-centric and platform-agnostic Workload specification to improve developer productivity and experience. It eliminates configuration management between environments. - - diff --git a/content/en/docs/glossary/score.md b/content/en/docs/glossary/score.md deleted file mode 100644 index e496c474..00000000 --- a/content/en/docs/glossary/score.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: Score implementation (CLI) -id: score -full_link: /docs/concepts/score/ -short_description: > - The Score implementation (CLI) is the tooling used to convert the Score Specification into the target platform configuration file of your choice. -tags: -- name -- fundamental ---- - -The Score implementation (CLI) is the tooling used to convert the Score Specification into the target platform configuration file of your choice. diff --git a/content/en/docs/glossary/workload-spec.md b/content/en/docs/glossary/workload-spec.md deleted file mode 100644 index fd520f76..00000000 --- a/content/en/docs/glossary/workload-spec.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: Workload specification -id: workload-spec -full_link: /docs/concepts/score/ -short_description: > - A Workload Specification file, or Workload Spec, is a single Workload specification file. -tags: -- workload -- fundamental ---- - -A Workload Specification file, or Workload Spec, is a single Workload specification file. diff --git a/content/en/docs/glossary/workload.md b/content/en/docs/glossary/workload.md deleted file mode 100644 index 9fa729ce..00000000 --- a/content/en/docs/glossary/workload.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: Workload -id: workload -full_link: /docs/concepts/score/ -short_description: > - A Workload is a deployable application made up of one or more containers that runs in the same context and share resources, dependencies and networks. -tags: -- workload -- fundamental ---- - -A Workload is a deployable application made up of one or more containers that runs in the same context and share resources, dependencies and networks. diff --git a/content/en/docs/override/_index.md b/content/en/docs/override/_index.md index 5d62cbe0..93f198f4 100644 --- a/content/en/docs/override/_index.md +++ b/content/en/docs/override/_index.md @@ -24,7 +24,7 @@ Alternatively, use the `--property` flag to specify individual properties to ove ## Overview -If an `overrides.score.yaml` file is found, the {{< glossary_tooltip text="Score implementation (CLI)" term_id="score" >}} applies overrides on the output. This occurs whether a flag is provided or not. +If an `overrides.score.yaml` file is found, the Score implementation (CLI) applies overrides on the output. This occurs whether a flag is provided or not. Any property of Score segment can be overridden. diff --git a/content/en/docs/overview/_index.md b/content/en/docs/overview/_index.md index e1e81cf2..574f4e97 100644 --- a/content/en/docs/overview/_index.md +++ b/content/en/docs/overview/_index.md @@ -6,6 +6,13 @@ Victor_Hugo: "true" Focus_Keyword: "Learn about the Score Specification" description: > Learn about Score, the Score implementation (CLI), and how to eliminate configuration mismanagement. +aliases: +- /docs/concepts +- /docs/concepts/container +- /docs/concepts/environment-configuration +- /docs/concepts/score +- /docs/concepts/workload +- /docs/glossary --- ## What is Score? @@ -20,7 +27,7 @@ The _Score implementation (CLI)_ is a conversion tool (such as score-compose or Developers use the Score Specification to describe their Workload, including its resource and service dependencies. -Then they run a {{< glossary_tooltip text="Score Implementation (CLI)" term_id="score" >}} to generate required resources in an environment of choice. +Then they run a Score Implementation (CLI) to generate required resources in an environment of choice. For example, the same Score Specification can be used to generate a docker compose file for local development, Kubernetes manifests for deployment to a shared development environment and to a serverless platform such as Google Cloud Run for integration tests. diff --git a/content/en/docs/reference/humanitec-extension.md b/content/en/docs/reference/humanitec-extension.md index 7dbdbe04..f1ad319a 100644 --- a/content/en/docs/reference/humanitec-extension.md +++ b/content/en/docs/reference/humanitec-extension.md @@ -25,7 +25,7 @@ resources: `apiVersion`: the declared Score Specification version. -- Valid options: `score.dev/v1b1` +- Valid options: `humanitec.org/v1b1` `profile`: describes a custom Workload profile name. diff --git a/content/en/docs/reference/score-cli/_index.md b/content/en/docs/reference/score-cli/_index.md index 8899cdfb..c26cfe07 100644 --- a/content/en/docs/reference/score-cli/_index.md +++ b/content/en/docs/reference/score-cli/_index.md @@ -8,7 +8,7 @@ description: > The _Score implementation (CLI)_ is a command-line tool used to interact with a Score Specification. Use a Score implementation (CLI) to transform your `score.yaml` file into multiple configuration files for the platform of your choice. -- [How to install the Score implementation (CLI)]({{< relref "/content/en/docs/Get started/install.md" >}} "Install") +- [How to install the Score implementation (CLI)]({{< relref "/docs/Get started/install.md" >}} "Install") - [Set environment-specific configuration to run Workloads in a target environment]({{< relref "/docs/environment%20variables/_index.md" >}} "Set environment-specific configuration to run Workloads in a target environment.") ## The Score implementation (CLI) diff --git a/content/en/docs/reference/score-spec-reference.md b/content/en/docs/reference/score-spec-reference.md index 4f8b1466..6708892d 100644 --- a/content/en/docs/reference/score-spec-reference.md +++ b/content/en/docs/reference/score-spec-reference.md @@ -64,7 +64,7 @@ The Resource section of the Score Specification allows users to describe the rel Resources can be anything and Score doesn't differentiate resources by types. The resource section can be used to provision multiservice setups with platforms like Docker Compose. -It is up to {{< glossary_tooltip text="Score implementation (CLI)" term_id="score" >}} to resolve the resource by name, type, or any other meta information available. +It is up to the Score implementation (CLI) to resolve the resource by name, type, or any other meta information available. ### Resources @@ -194,7 +194,7 @@ service: ## Container definition -The {{< glossary_tooltip text="Workload" term_id="workload" >}} container’s specification describes how the Workload's tasks are executed. +The Workload container’s specification describes how the Workload's tasks are executed. ```yaml image: string