Sandbox Deployment#

Tags: Kubernetes, Infrastructure, Basic

A sandbox deployment of Flyte bundles together portable versions of Flyte’s dependencies such as a relational database and durable object store.

For the blob store requirements, Flyte Sandbox uses Minio, which offers an S3 compatible interface, and for Postgres, it uses the stock Postgres Docker image and Helm chart.

Important

The sandbox deployment is not suitable for production environments. For instructions on how to create a production-ready Flyte deployment, checkout the Deployment Paths guide.

Flyte Sandbox as a Single Docker Container#

Flyte provides a way for creating a Flyte cluster as a self-contained Docker image. This is mini-replica of an entire Flyte deployment, without the scalability and with minimal extensions.

The Flyte Sandbox can be run on any environment that supports containers and makes it extremely easy for users of Flyte to try out the platform and get a feel for the user experience, all without having to understand Kubernetes or dabble with configuration.

Note

The Flyte single container sandbox is also used by the team to run continuous integration tests and used by the User guide, Tutorials and Integrations documentation.

Requirements#

  • Install kubectl.

  • Install docker or any other OCI-compatible tool, like Podman or LXD.

  • Install flytectl, the official CLI for Flyte.

While Flyte can run any OCI-compatible task image using the default Kubernetes container runtime (containerd), the Flyte core maintainers typically use Docker. Note that the flytectl demo command does rely on Docker APIs, but as this demo environment is just one self-contained image, you can also run the image directly using another run time.

Within the single container environment, a mini Kubernetes cluster is installed using k3s. K3s uses an in-container Docker daemon, run using docker-in-docker configuration to orchestrate user containers.

Start the Sandbox#

To spin up a Flyte Sandbox, run:

flytectl demo start

This command runs a Docker container, which itself comes with a Docker registry on localhost:30000 so you can build images outside of the docker-in-docker container by tagging your containers with localhost:30000/imgname:tag and pushing the image.

The local Postgres installation is also available on port 30001 for users who wish to dig deeper into the storage layer.

Expected Output:

πŸ‘¨β€πŸ’» Flyte is ready! Flyte UI is available at http://localhost:30080/console πŸš€ πŸš€ πŸŽ‰
❇️ Run the following command to export sandbox environment variables for accessing flytectl
  export FLYTECTL_CONFIG=~/.flyte/config-sandbox.yaml
πŸ‹ Flyte sandbox ships with a Docker registry. Tag and push custom workflow images to localhost:30000
πŸ“‚ The Minio API is hosted on localhost:30002. Use http://localhost:30080/minio/login for Minio console

Configuration#

The config-sandbox.yaml file contains configuration for FlyteAdmin, which is the Flyte cluster backend component that processes all client requests such as workflow executions. The default values are enough to let you connect and use Flyte:

admin:
  # For GRPC endpoints you might want to use dns:///flyte.myexample.com
  endpoint: localhost:30080
  authType: Pkce
  insecure: true
  console:
    endpoint: http://localhost:30080
logger:
  show-source: true
level: 0

Note

You can also create your own config file with flytectl config init, which will create a config file at ~/.flyte/config.yaml.

Learn more about the configuration settings in the {ref}`Deployment Guide <flyteadmin-config-specification>`

Now that you have the sandbox cluster running, you can now go to the User Guide or Tutorials to run tasks and workflows written in flytekit, the Python SDK for Flyte.