diff --git a/.gitignore b/.gitignore index ae80a752cc..738dd42f47 100644 --- a/.gitignore +++ b/.gitignore @@ -125,4 +125,4 @@ Cargo.lock .direnv # Lerna debug -lerna-debug.log \ No newline at end of file +lerna-debug.log diff --git a/docs/docs/api-reference/starlark-reference/image-spec.md b/docs/docs/api-reference/starlark-reference/image-spec.md new file mode 100644 index 0000000000..ba7a76735f --- /dev/null +++ b/docs/docs/api-reference/starlark-reference/image-spec.md @@ -0,0 +1,43 @@ +--- +title: ImageSpec +sidebar_label: ImageSpec +--- + +The `ImageSpec` object constructor allows for providing detailed information about a container image for use in the [`ServiceConfig.image`](./service-config.md) property. It is most commonly used when pulling an image from a non-Dockerhub container repository. + +Signature +--------- + +``` +ImageSpec( + name, + registry = "http://hub.docker.com", + username = None, + password = None, +) +``` + +| Property | Description | +| --- | --- | +| **name**
_string_ | The name of the container image that should be used. | +| **registry**
_string_ | The registry that the container should be pulled from. | +| **username**
_string_ | The username that will be used for connecting to the registry when pulling the image. | +| **password**
_string_ | The password that will be used for connecting to the registry when pulling the image. | + +Examples +-------- +Starting a service called `my-service` from `my.registry.io` using a custom username and password: + +```python +plan.add_service( + name = "my-service", + config = ServiceConfig( + image = ImageSpec( + name = "my.registry.io/some-org/some-image", + registry = "http://my.registry.io/", + username = "registry-user", + password = "SomePassword1!", + ) + ) +) +``` diff --git a/docs/docs/api-reference/starlark-reference/service-config.md b/docs/docs/api-reference/starlark-reference/service-config.md index 2c9aa35378..e9633aef7e 100644 --- a/docs/docs/api-reference/starlark-reference/service-config.md +++ b/docs/docs/api-reference/starlark-reference/service-config.md @@ -3,274 +3,157 @@ title: ServiceConfig sidebar_label: ServiceConfig --- -The `ServiceConfig` is used to configure a service when it is added to an enclave (see [add_service][add-service-reference]). +The `ServiceConfig` object constructor configures the parameters of a container for the [`plan.add_service`][add-service-reference] function. -```python -config = ServiceConfig( - # The name of the container image that Kurtosis will use to create and start the service's container. - # This image can be pulled from a remote container registry, picked up from the local cache, or built by Kurtosis using - # the underlying container engine. - # If a string is provided, Kurtosis will by default detect if images exists locally, or pull from container registry if not. - # The string form is syntactic sugar for ImageSpec with only image set - # ImageSpec referring to private registries limited to Docker - # Reach out to the team if you want to run Kurtosis with private images on Kubernetes - # If an ImageBuildSpec is provided, Kurtosis will build the image. - # MANDATORY - image = "kurtosistech/example-datastore-server", - - OR - - image = ImageSpec( - # The name of the image that needs to be pulled qualified with the registry - # MANDATORY - name = "my.registry.io/my-user/my-image", - - # The username that will be used to pull the image from the given registry - # OPTIONAL - username = "my-user", - - # The password that will be used to pull the image from the given registry - # OPTIONAL - password = "password", - - # The URL of the registry - # OPTIONAL - registry = "http://my.registry.io/" - ) - - OR - - image = ImageBuildSpec( - # Name to give built image - # MANDATORY - image_name="kurtosistech/example-datastore-server" - - # Locator to build context within the Kurtosis package - # As of now, Kurtosis expects a Dockerfile at the root of the build context - # MANDATORY - build_context_dir="./server" - - # Stage of image build to target for multi-stage container image - # OPTIONAL - target_stage="" - ) - - OR - - image = NixBuildSpec( - # The name of the image that needs to be pulled qualified with the registry - # MANDATORY - image_name = "hello-world-server", - - # Locator to build context within the Kurtosis package - # This allows to select a sub-package where the context is going be used to build the image - # MANDATORY - build_context_dir = "./" - - # The relative path (from the `build_context_dir`) to the folder containing the flake.nix file - # MANDATORY - flake_location_dir = "./hello-go", - - # The selector for the Flake output with the image derivation. Fallbacks to the default package. - flake_output = "containerImage", - ) - - # The ports that the container should listen on, identified by a user-friendly ID that can be used to select the port again in the future. - # Kurtosis will automatically perform a check to ensure all declared UDP and TCP ports are open and ready for traffic and connections upon startup. - # You may specify a custom wait timeout duration or disable the feature entirely, learn more via PortSpec docs - # If no ports are provided, no ports will be exposed on the host machine, unless there is an EXPOSE in the Dockerfile. - # OPTIONAL (Default: {}) - ports = { - "grpc": PortSpec( - # The port number which we want to expose - # MANDATORY - number = 3000, - - # Transport protocol for the port (can be either "TCP" or "UDP") - # Optional (DEFAULT:"TCP") - transport_protocol = "TCP", - - # Application protocol for the port - # Optional - application_protocol = "http", - # Kurtosis will automatically perform a check to ensure all declared UDP and TCP ports are open and ready for traffic and connections upon startup. - # You may specify a custom wait timeout duration or disable the feature entirely. - # You may specify a custom wait timeout duration with a string: - # wait = "2m" - # Or, you can disable this feature by setting the value to None: - # wait = None - # The feature is enabled by default with a default timeout of 15s - # OPTIONAL (DEFAULT:"15s") - wait = "4s" - ), - }, - - # A mapping of path_on_container_where_contents_will_be_mounted -> Directory object or file artifact name - # For more info on what a Directory object is, see below - # - # OPTIONAL (Default: {}) - files = { - "path/to/files/artifact_1/": files_artifact_1, - "path/to/files/artifact_2/": Directory( - artifact_names=[files_artifact_2], - ), - "path/to/persistent/directory/": Directory( - persistent_key="data-directory", - ), - }, - - # The ENTRYPOINT statement hardcoded in a container image's Dockerfile might not be suitable for your needs. - # This field allows you to override the ENTRYPOINT when the container starts. - # OPTIONAL (Default: []) - entrypoint = [ - "bash", - ], - - # The CMD statement hardcoded in a container image's Dockerfile might not be suitable for your needs. - # This field allows you to override the CMD when the container starts. - # OPTIONAL (Default: []) - cmd = [ - "-c", - "sleep 99", - ], - - # Defines environment variables that should be set inside the Docker container running the service. - # This can be necessary for starting containers from Docker images you don’t control, as they’ll often be parameterized with environment variables. - # OPTIONAL (Default: {}) - env_vars = { - "VAR_1": "VALUE_1", - "VAR_2": "VALUE_2", - }, - - # ENTRYPOINT, CMD, and ENV variables sometimes need to refer to the container's own IP address. - # If this placeholder string is referenced inside the 'entrypoint', 'cmd', or 'env_vars' properties, the Kurtosis engine will replace it at launch time - # with the container's actual IP address. - # OPTIONAL (Default: "KURTOSIS_IP_ADDR_PLACEHOLDER") +Signature +--------- +```python +ServiceConfig( + image, + ports = {}, + env_vars = {}, + files = {}, + entrypoint = None, + cmd = None, private_ip_address_placeholder = "KURTOSIS_IP_ADDRESS_PLACEHOLDER", + min_cpu = None, + max_cpu = None, + min_memory = None, + max_memory = None, + ready_conditions = [], + labels = {}, + user = None, + tolerations = None, + node_selectors = None, +) +``` - # The maximum amount of CPUs the service can use, in millicpu/millicore. - # OPTIONAL (Default: no limit) - max_cpu = 1000, - - # The minimum amout of CPUs the service must have, in millicpu/millicore. - # CAUTION: This is only available for Kubernetes, and will be ignored for Docker. - # OPTIONAL (Default: no limit) - min_cpu = 500, - - # The maximum amount of memory, in megabytes, the service can use. - # OPTIONAL (Default: no limit) - max_memory = 1024, - - # The minimum amount of memory, in megabytes, the service must have. - # CAUTION: This is only available for Kubernetes, and will be ignored for Docker. - # OPTIONAL (Default: no limit) - min_memory = 512, - - # This field can be used to check the service's readiness after the service has started, - # to confirm that it is ready to receive connections and traffic - # OPTIONAL (Default: no ready conditions) - ready_conditions = ReadyCondition(...), - - # This field is used to specify custom labels at the container level in Docker and Pod level in Kubernetes. - # For Docker, the label syntax and format will follow: "com.kurtosistech.custom.key": "value" - # For Kubernetes, the label syntax & format will follow: kurtosistech.com.custom/key=value - - # Labels must follow the label standards outlined in [RFC-1035](https://datatracker.ietf.org/doc/html/rfc1035), - # meaning that both the label key and label value must contain at most 63 characters, contain only lowercase - # alphanumeric characters, dashes (-), underscores (_) or dots (.), start with an alphabetic character, and end with an alphanumeric character. - # Empty value and capital letters are valid on label values. - # OPTIONAL - labels = { - "key": "value", - # Examples - "name": "alice", - } +| Property | Description | +| --- | --- | +| **image**
_string\|[ImageSpec][image-spec]\|[ImageBuildSpec][image-build-spec]\|[NixBuildSpec][nix-build-spec]_ | The container image that will be used to back the service.

This can a simple container image string just like you'd feed to `docker run`, or a more complex specification instructing Kurtosis to build an image on demand.

If a `string` is provided, the string will be treated as an image identifier just like you'd use in `docker run`. `name = "IMAGE"` is merely syntactic sugar for `ImageSpec(name = "IMAGE")`.

If an [`ImageSpec`][image-spec] is provided, then the information provided in the `ImageSpec` will be used to pull the image.

If an [`ImageBuildSpec`][image-build-spec] is provided, Kurtosis will build the image using the provided Dockerfile information upon every run.

If a [`NixBuildSpec`][nix-build-spec] is provided, Kurtosis will build the image using the provided Nix Flake information | +| **ports**
_dict\[string, [PortSpec][port-spec]]_ | A mapping defining the ports that the container will be listening on, with the keys being user-friendly port names and the values being [`PortSpec`][port-spec] objects defining information about the ports.

The port names specified in this map will correspond to the ports on the [`Service`][service] object returned by [`plan.add_service`][add-service-reference].

Kurtosis will automatically check to ensure all declared TCP ports are open and ready for connections upon container startup. This behaviour can be disabled in the [`PortSpec`][port-spec] configuration.

If no ports are provided, no ports will be exposed unless the container image's Dockerfile has an `EXPOSE` directive. | +| **env_vars**
_dict\[string, string]_ | A mapping of environment variable names to values that should be set when running the container.
Any [future reference strings][future-references] used in the value will be replaced at runtime with the actual value. | +| **files**
_dict\[string, string\|[Directory][directory]]_ | A mapping of filepaths to the files that should be mounted there.

If a string value is provided, the [files artifact][files-artifacts] matching the same name will be mounted at that path. This is syntactic sugar for the more verbose `Directory(artifact_names=["artifact-name"])`.

If a [`Directory`][directory] value is provided, the provided configuration will be used to configure the mounted files. | +| **entrypoint**
_list\[string]_ | Overrides the `ENTRYPOINT` setting of the container image.

If `None` is provided, then the default `ENTRYPOINT` setting on the container image will be used.

If `list[string]` is provided, then the `ENTRYPOINT` will be overridden with the given strings. Any [future reference strings][future-references] used will be replaced at runtime with the actual value. | +| **cmd**
_list\[string]_ | Overrides the `CMD` setting of the container image.

If `None` is provided, then the default `CMD` setting on the container image will be used.

If `list[string]` is provided, then the `CMD` will be overridden with the given strings. Any [future reference strings][future-references] used will be replaced at runtime with the actual value.

**💁 TIP:** If you are trying to use a more complex versions of `cmd` and are running into issues, we recommend using `cmd` in combination with `entrypoint`. You can set `entrypoint = ["/bin/sh", "-c"]` and then set the `cmd` to the command as you would type it in your shell (e.g. `cmd = ["echo foo | grep foo"]`). | +| **private_ip_address_placeholder**
_string_ | On occasion, the `entrypoint`, `cmd`, and `env_vars` properties may need to know the IP address of the container before it exists. If the value of `private_ip_address_placeholder` is included in these properties, the placeholder value will be replaced with the container's actual IP address at runtime. | +| **min_cpu**
_int_ | Controls the minimum amount of CPU that a service is allocated, in millicpus/millicores.

If set to `None`, then the service will not have any CPU set aside just for it.

If set to a non-`None` integer, the service will be allocated the specified number of millicpus.

**⚠️ CAUTION:** Docker doesn't have a setting to enforce this, so this option will only be used on Kubernetes. | +| **max_cpu**
_int_ | Controls the maximum amount of CPU that a service is allowed to consume, in millicpus/millicores.

If set to `None`, then the service will not have any CPU limits set for it.

If set to a non-`None` integer, the service will be capped to the specified number of millicpus. | +| **min_memory**
_int_ | Controls the minimum amount of memory that a service is allocated, in megabytes.

If set to `None`, then the service will not have any memory set aside just for it.

If set to a non-`None` integer, the service will be allocated the specified number of megabytes.

**⚠️ CAUTION:** Docker doesn't have a setting to enforce this, so this option will only be used on Kubernetes. | +| **max_memory**
_int_ | Controls the maximum amount of memory that a service is allowed to consume, in megabytes.

If set to `None`, then the service will not have any memory limits set for it.

If set to a non-`None` integer, the service will be capped to the specified number of megabytes. | +| **ready_conditions**
_list[[ReadyCondition][ready-condition]]_ | Defines a set of [`ReadyCondition`][ready-condition] checks that must pass before Kurtosis considers the service started.

If any ReadyCondition doesn't pass, Kurtosis considers the service as having failed to start. | +| **labels**
_dict\[string, string]_ | A mapping of string keys to values used to attach custom labels to the containers that Kurtosis starts. This can be useful if you have automation consuming the Kurtosis enclave.

For Docker, providing `labels={"KEY":"VALUE"}` will result in the container label `"com.kurtosistech.custom.KEY": "VALUE"`.

For Kubernetes, providing `labels={"KEY":"VALUE"}` will result in the Pod label `kurtosistech.com.custom/KEY=VALUE`. | +| **user**
_[User][user]_ | The user to start the container with. This is useful when you need to override the user ID or group ID that a container runs under. | +| **tolerations**
_list[[Toleration][toleration]]_ | When running on Kubernetes, creates Kubernetes [Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) for each entry in the given list. Requires at least one untainted node to function.

**⚠️ WARNING:** This is an experimental feature that might get replaced with a better abstraction in the future.

**📝 NOTE:** Has no effect on Docker. | +| **node_selectors**
_dict\[string, string]_ | Refers to Kubernetes [Node Selectors](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/#create-a-pod-that-gets-scheduled-to-your-chosen-node), used to control which nodes a Pod is scheduled on.
For example, `node_selectors = {"disktype": "ssd"}` could be used to schedule the service only on nodes with the `disktype=ssd` label.

**⚠️ WARNING:** This is an experimental feature that might get replaced with a better abstraction in the future.

**📝 NOTE:** Has no effect on Docker. | + +Basic Examples +----------- +You'll most frequently use the `image`, `ports`, `env_vars`, and `files` args. Occasionally, you'll need the `entrypoint` and `cmd` args. + +### Postgres with preseeded data - # The user id and group id to start the container with - # Some containers are configured to start with users other than root by default; this allows you to override to root or other - # users if you choose to. - # Note that the `gid` field is optional - # OPTIONAL - user = User(uid=0, gid=0), - - # An array of Toleration - # This refers to Kubernetes Tolerations https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ - # This has no effect on Docker - # As of 2024-01-24 Taints and Tolerations to work with Kubernetes you need at least one untainted node - # Refer to the Toleration docs linked near the end of the page to learn more - # OPTIONAL - tolerations = [ - Toleration( - key = "test-key", - value = "test-value", - operator = "Equal", - effect = "NoSchedule", - toleration_seconds = 64, - ) - ], - - # A map of node selectors - # This refers to Node Selectors in Kubernetes https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector - # This has no effect on Docker - # This is an experimental feature that might get replaced with a better abstraction suited for Kurtosis - # OPTIONAL - node_selectors = { - "disktype": "ssd", - } +```python +init_sql = plan.render_templates({ + "init.sql": struct( + template = """ +CREATE TABLE students ( +id SERIAL PRIMARY KEY, +name VARCHAR(100), +age INTEGER +); + +INSERT INTO students (name, age) VALUES +('Mkyong', 40), +('Ali', 28), +('Teoh', 18); +""", + data={} + ), +}) + +plan.add_service( + name = "postgres", + config = ServiceConfig( + image = "postgres", + ports = { + "postgres": PortSpec(number = 5432, application_protocol = "postgresql"), + }, + env_vars = { + "POSTGRES_USER": "teacher", + "POSTGRES_PASSWORD": "bookworm", + "POSTGRES_DB": "students", + }, + files = { + "/docker-entrypoint-initdb.d": init_sql, + }, + ) ) ``` -Note that `ImageBuildSpec` can only be used in packages and not standalone scripts as it relies on build context in package. More info on [`ImageBuildSpec`](./image-build-spec.md) here. -More info can be found on [locators referring to local resources here][locators] and how to turn your script into a Kurtosis [package][package] here. -The `ports` dictionary argument accepts a key value pair, where `key` is a user defined unique port identifier and `value` is a [PortSpec][port-spec] object. +### Persisting data through service restarts +The `Directory.persistent_key` property can be used to indicate that data should be persisted through service restarts: -The `files` dictionary argument accepts a key value pair, where `key` is the path where the contents of the artifact will be mounted to and `value` is a [Directory][directory] object or files artifact name. -Using a `Directory` object with `artifact_name` is strictly equivalent to directly using the files artifact name as the value of the dictionary. This is just to simplify usage. +```python +plan.add_service( + name = "postgres", + config = ServiceConfig( + image = "postgres", + ports = { + "postgres": PortSpec(number = 5432, application_protocol = "postgresql"), + }, + env_vars = { + "POSTGRES_USER": "teacher", + "POSTGRES_PASSWORD": "bookworm", + "POSTGRES_DB": "students", + }, + files = { + "/var/lib/postgresql/data": Directory(persistent_key = "pgdata") + }, + ) +) +``` -See [Nix Support][nix-support] for more information on how to use the Nix and Kurtosis together. + -:::tip Example of a rendered label -If you have defined the pod label key:value pair in `ServiceConfig` to be: +Advanced Examples +-------------- +### Assigning custom labels +Suppose you've defined the following `ServiceConfig`: -```py -config = ServiceConfig( - ... +```python +ServiceConfig( + image = "postgres", labels = { "name": "alice", - "age": "20", - "height": "175" + "age": "20", + "height": "175", } ) ``` -then the labels for the pods on Kubernetes will look like: +When running on Kubernetes, the labels for the Pod running the service will look like: ``` -labels: - kurtosistech.com.custom/name=alice - kurtosistech.com.custom/age=20 - kurotsistech.com.custom/height=175 +kurtosistech.com.custom/name=alice +kurtosistech.com.custom/age=20 +kurotsistech.com.custom/height=175 ``` -while on Docker, the container labels will look like: +When running on Docker, the container labels will look like: ``` -labels: - "com.kurtosistech.custom.name": "alice" - "com.kurtosistech.custom.age": "20" - "com.kurtosistech.custom.height": "175" +"com.kurtosistech.custom.name": "alice" +"com.kurtosistech.custom.age": "20" +"com.kurtosistech.custom.height": "175" ``` -::: - -The `user` field expects a [`User`][user] object being passed. - -The `tolerations` field expects a list of [`Toleration`][toleration] objects being passed. [add-service-reference]: ./plan.md#add_service @@ -282,3 +165,9 @@ The `tolerations` field expects a list of [`Toleration`][toleration] objects bei [user]: ./user.md [toleration]: ./toleration.md [nix-support]: ./nix-support.md +[future-references]: ../../advanced-concepts/future-references.md +[files-artifacts]: ../../advanced-concepts/files-artifacts.md +[service]: ./service.md +[image-spec]: ./image-spec.md +[image-build-spec]: ./image-build-spec.md +[nix-build-spec]: ./nix-support.md diff --git a/docs/docs/get-started/basic-concepts.md b/docs/docs/get-started/basic-concepts.md index 1c3f4a604e..18a2e20e04 100644 --- a/docs/docs/get-started/basic-concepts.md +++ b/docs/docs/get-started/basic-concepts.md @@ -5,41 +5,51 @@ slug: '/basic-concepts' sidebar_position: 4 --- -Package +Enclave ----------- +An enclave is a logical grouping concept, a "walled garden" in which Kurtosis runs a microservice stack. Each Kurtosis instance can have many enclaves, and each enclave is isolated so that port and file conflicts don't occur. The enclaves and the services inside of them get mapped down into Docker or Kubernetes concepts, depending on your backend. -A package defines the set up logic for a containerized backend. Packages can be accessed via Github locators. +![enclaves.png](../../static/img/getting-started/enclaves.png) -```console -kurtosis run github.com/kurtosis-tech/basic-service-package -``` +_Multiple enclaves can run on a single Kurtosis instance._ -Packages can accept a set of parameters, defined by the package author, which enable the package consumer to modify their deployed backend at a high-level without needing to know how to configure each individual service. +Enclaves are cheap to create and cheap to destroy. They won't leave any resources hanging around after deletion. -```console -kurtosis run github.com/kurtosis-tech/basic-service-package \ - '{"service_a_count": 2, - "service_b_count": 2, - "service_c_count": 1, - "party_mode": true}' -``` +![delete-enclaves.png](../../static/img/getting-started/delete-enclaves.png) -Enclave +_Deleting enclaves is easy._ + +Package ----------- +A package contains the setup logic for a microservice stack, and serves as a distribution mechanism. + +![package-catalog.png](../../static/img/getting-started/package-catalog.png) + +_Many packages are already available on the [Package Catalog](https://catalog.kurtosis.com/)._ + +Packages can be composed together to form new microservices stacks, which can themselves be distributed as packages. -An enclave is a "walled garden" in which Kurtosis runs a containerized backend. Enclaves can run anywhere that you have a Docker engine or a Kubernetes cluster. The main purposes of an enclave are resource isolation and "garbage collection". +Each package is identified by a "locator", which is a URL-like string uniquely identifying the package. For example, `github.com/kurtosis-tech/postgres-package`. + +Packages can can be configured using parameters, which allows package consumers to flex their microservice stack without knowing the inner workings of the stack. + +![package-params.png](../../static/img/getting-started/package-params.png) + +_Kurtosis provides tooling for authors to document their package parameters._ -With an "enclave remove" command (`kurtosis enclave rm`), you can destroy all of the resources used to set up your environment and leave nothing hanging around on your machine(s). Files Artifact ----------- - A files artifact is a set of files shipped with, or generated by, a package. Files artifacts are typically used for rendering configuration files that must be dynamically generated when an environment spins up, or for shipping static configuration files that must be shared across multiple services. -When you run a package, you can see the files artifacts that the package uses in the enclave output: +When you run a package, you can see the files artifacts that the package created in the enclave. + +![files-artifacts.png](../../static/img/getting-started/files-artifacts.png) + +_Several files artifacts in an enclave._ + +Files artifacts are just `.tgz` files, so exploring their contents is easy. -```console -kurtosis run github.com/kurtosis-tech/basic-service-package -``` +![files-artifact-overview.png](../../static/img/getting-started/files-artifact-overview.png) -![files-artifact-output-concepts.png](/img/home/files-artifact-output-concepts.png) \ No newline at end of file +_Contents of a files artifact called `prometheus-config`._ diff --git a/docs/docs/get-started/get-started.md b/docs/docs/get-started/get-started.md index 6acedd6e4f..1bbafacf47 100644 --- a/docs/docs/get-started/get-started.md +++ b/docs/docs/get-started/get-started.md @@ -6,10 +6,10 @@ sidebar_position: 1 hide_table_of_contents: true --- -[Kurtosis](https://github.com/kurtosis-tech/kurtosis) is a tool for packaging and launching environments of containerized services where you want them, the way you want them, with one liners. +[Kurtosis](https://github.com/kurtosis-tech/kurtosis) is a tool for packaging and launching microservice stacks where you want them, the way you want them, with one liners. - Get started with a [quickstart](quickstart.md) to launch an environment. -- Dive deeper with [basic Kurtosis concepts](basic-concepts.md). +- Learn about the [basic Kurtosis concepts](basic-concepts.md). - Write your own environment definition with a guide on [writing a package](write-your-first-package.md). To quickly see what Kurtosis feels like, check out the example snippets below: @@ -79,4 +79,4 @@ kurtosis run github.com/kurtosis-tech/basic-service-package \ ![service-c-partying.png](/img/home/service-c-k8s.png) - \ No newline at end of file + diff --git a/docs/docs/get-started/installing-the-cli.md b/docs/docs/get-started/installing-the-cli.md index dfbba8fae5..291a17d1f5 100644 --- a/docs/docs/get-started/installing-the-cli.md +++ b/docs/docs/get-started/installing-the-cli.md @@ -4,6 +4,7 @@ id: installing-the-cli sidebar_label: Install Kurtosis slug: /install sidebar_position: 2 +toc_max_header: 2 --- diff --git a/docs/docusaurus.config.js b/docs/docusaurus.config.js index e84c675db0..2840961450 100644 --- a/docs/docusaurus.config.js +++ b/docs/docusaurus.config.js @@ -88,15 +88,16 @@ const config = { activeBasePath: '/sdk' }, { - href: 'https://www.kurtosis.com/release-notes', + to: '/whats-new', position: 'left', - label: 'Release Notes', - }, - { - href: 'https://github.com/kurtosis-tech/kurtosis/issues/new?assignees=leeederek&labels=docs&template=docs-issue.yml', - position: 'right', - label: 'Report Docs Issue', + label: "What's New", + activeBasePath: '/whats-new' }, + { + href: 'https://github.com/kurtosis-tech/kurtosis/', + position: 'right', + className: 'header-github-link', + } ], }, footer: { diff --git a/docs/src/css/custom.css b/docs/src/css/custom.css index 3e11ab01c7..3f98e0b55f 100644 --- a/docs/src/css/custom.css +++ b/docs/src/css/custom.css @@ -54,6 +54,22 @@ main { background-color: #111111; } +.header-github-link::before { + content: ''; + width: 24px; + height: 24px; + display: flex; + background-color: var(--ifm-navbar-link-color); + mask-image: url("data:image/svg+xml,%3Csvg viewBox='0 0 24 24' xmlns='http://www.w3.org/2000/svg'%3E%3Cpath d='M12 .297c-6.63 0-12 5.373-12 12 0 5.303 3.438 9.8 8.205 11.385.6.113.82-.258.82-.577 0-.285-.01-1.04-.015-2.04-3.338.724-4.042-1.61-4.042-1.61C4.422 18.07 3.633 17.7 3.633 17.7c-1.087-.744.084-.729.084-.729 1.205.084 1.838 1.236 1.838 1.236 1.07 1.835 2.809 1.305 3.495.998.108-.776.417-1.305.76-1.605-2.665-.3-5.466-1.332-5.466-5.93 0-1.31.465-2.38 1.235-3.22-.135-.303-.54-1.523.105-3.176 0 0 1.005-.322 3.3 1.23.96-.267 1.98-.399 3-.405 1.02.006 2.04.138 3 .405 2.28-1.552 3.285-1.23 3.285-1.23.645 1.653.24 2.873.12 3.176.765.84 1.23 1.91 1.23 3.22 0 4.61-2.805 5.625-5.475 5.92.42.36.81 1.096.81 2.22 0 1.606-.015 2.896-.015 3.286 0 .315.21.69.825.57C20.565 22.092 24 17.592 24 12.297c0-6.627-5.373-12-12-12'/%3E%3C/svg%3E"); + transition: background-color var(--ifm-transition-fast) + var(--ifm-transition-timing-default); +} + +.header-github-link:hover::before { + background-color: var(--ifm-navbar-link-hover-color); +} + + /*Stlying for search bar*/ [data-theme='light'] .DocSearch { /* --docsearch-primary-color: var(--ifm-color-primary); */ @@ -93,4 +109,4 @@ main { var(--ifm-color-emphasis-200) 0%, var(--ifm-color-emphasis-100) 100% ); -} \ No newline at end of file +} diff --git a/docs/static/img/getting-started/delete-enclaves.png b/docs/static/img/getting-started/delete-enclaves.png new file mode 100644 index 0000000000..e1da45c2e4 Binary files /dev/null and b/docs/static/img/getting-started/delete-enclaves.png differ diff --git a/docs/static/img/getting-started/enclaves.png b/docs/static/img/getting-started/enclaves.png new file mode 100644 index 0000000000..13099793eb Binary files /dev/null and b/docs/static/img/getting-started/enclaves.png differ diff --git a/docs/static/img/getting-started/files-artifact-overview.png b/docs/static/img/getting-started/files-artifact-overview.png new file mode 100644 index 0000000000..7076a960cd Binary files /dev/null and b/docs/static/img/getting-started/files-artifact-overview.png differ diff --git a/docs/static/img/getting-started/files-artifacts.png b/docs/static/img/getting-started/files-artifacts.png new file mode 100644 index 0000000000..384253cfa5 Binary files /dev/null and b/docs/static/img/getting-started/files-artifacts.png differ diff --git a/docs/static/img/getting-started/package-catalog.png b/docs/static/img/getting-started/package-catalog.png new file mode 100644 index 0000000000..18b33cfb5b Binary files /dev/null and b/docs/static/img/getting-started/package-catalog.png differ diff --git a/docs/static/img/getting-started/package-params.png b/docs/static/img/getting-started/package-params.png new file mode 100644 index 0000000000..1c70111fbc Binary files /dev/null and b/docs/static/img/getting-started/package-params.png differ