<commit_before># Ambassador Configuration

At the heart of Ambassador are the ideas of [_modules_](#modules), [_mappings_](#mappings), [_resources_](#resources)], and soon [_consumers_](#consumers).

- [Modules](#modules) let you enable and configure special behaviors for Ambassador, in ways which may apply to Ambassador as a whole or which may apply only to some mappings. For example, the `authentication` module allows Ambassador to require authentication per mapping.

- [Mappings](#mappings) associate REST _resources_ with Kubernetes _services_. Ambassador _must_ have one or more mappings defined to provide access to any services at all.

- [Consumers](#consumers) represent human end users of Ambassador. More here later.

Ambassador assembles its configuration from YAML files contained within a single directory on the filesystem. Each file must have a name that ends in `.yaml`, and Ambassador fully supports multiple documents in a single file.

When run as part of an image build, the caller must tell Ambassador the path to the directory; when run as a proxy pod within Kubernetes, Ambassador assumes that its configuration has been published as a `ConfigMap` named `ambassador-config`. The easiest way to create such a `ConfigMap` is to assemble a directory of appropriate YAML files, and use 

```shell
kubectl create configmap ambassador-config --from-file config-dir-path
```

to publish the configuration.

### Best Practices for Configuration Files

Ambassador uses a directory structure for its configuration to allow multiple developers to more easily collaborate on a microservice application: developers working on a given microservice can create a mapping file for their single microservice without having to worry about stepping on other developers, etc. This implies a few things:

- Ambassador's configuration should be under version control.

    Having the configuration directory under git or the like is an obvious thought here. Ambassador doesn't do any versioning of its configuration.

- Be aware that Ambassador tries to not start with a broken configuration, but it's not perfect.

    Gross errors will result in Ambassador refusing to start, in which case `kubectl logs` will be helpful. However, it's always possible to e.g. map a resource to the wrong service, or using the wrong `rewrite` rules. Ambassador can't detect that on its own.

- Be careful of mapping collisions.

    If two different developers try to map `/user/` to something, Ambassador should catch it and refuse to start, but it's still not what you want (obviously).

## Namespaces
<commit_msg>Typo fix.<commit_after># Ambassador Configuration

At the heart of Ambassador are the ideas of [_modules_](#modules), [_mappings_](#mappings), and [_resources_](#resources).

- [Modules](#modules) let you enable and configure special behaviors for Ambassador, in ways which may apply to Ambassador as a whole or which may apply only to some mappings. For example, the `authentication` module allows Ambassador to require authentication per mapping.

- [Mappings](#mappings) associate REST _resources_ with Kubernetes _services_. Ambassador _must_ have one or more mappings defined to provide access to any services at all.

- [Resources](#resources) are as defined in REST: effectively groups of one or more URLs that all share a common prefix in the URL path.

Ambassador assembles its configuration from YAML files contained within a single directory on the filesystem. Each file must have a name that ends in `.yaml`, and Ambassador fully supports multiple documents in a single file.

When run as part of an image build, the caller must tell Ambassador the path to the directory; when run as a proxy pod within Kubernetes, Ambassador assumes that its configuration has been published as a `ConfigMap` named `ambassador-config`. The easiest way to create such a `ConfigMap` is to assemble a directory of appropriate YAML files, and use 

```shell
kubectl create configmap ambassador-config --from-file config-dir-path
```

to publish the configuration.

### Best Practices for Configuration Files

Ambassador uses a directory structure for its configuration to allow multiple developers to more easily collaborate on a microservice application: developers working on a given microservice can create a mapping file for their single microservice without having to worry about stepping on other developers, etc. This implies a few things:

- Ambassador's configuration should be under version control.

    Having the configuration directory under git or the like is an obvious thought here. Ambassador doesn't do any versioning of its configuration.

- Be aware that Ambassador tries to not start with a broken configuration, but it's not perfect.

    Gross errors will result in Ambassador refusing to start, in which case `kubectl logs` will be helpful. However, it's always possible to e.g. map a resource to the wrong service, or using the wrong `rewrite` rules. Ambassador can't detect that on its own.

- Be careful of mapping collisions.

    If two different developers try to map `/user/` to something, Ambassador should catch it and refuse to start, but it's still not what you want (obviously).

## Namespaces

{'fraction_non_alphanumeric': 0.0497131931166348, 'fraction_numerical': 0.0, 'mean_word_length': 4.754675467546755, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4098967', 'n_tokens_mistral': 1253, 'n_tokens_neox': 1144, 'n_words': 752}