Set up the containers and services managed by an app¶

Create an image repository¶

To manage containers with a Snowflake Native App, providers must create an image repository in the provider account to store the images required by the app.

The image repository must exist within a database and schema. The following example shows how to create an image repository using the CREATE IMAGE REPOSITORY command.

CREATE DATABASE provider_db;
CREATE SCHEMA provider_schema;
CREATE IMAGE REPOSITORY provider_repo;

The images uploaded to this repository are accessible to the application package when adding a version definition. The app has can only access the images in this repository that are specified in the manifest file of the application package.

The following consideration apply to image repositories in the context of an app with containers:

• External image repositories are not supported. Image repositories that are outside Snowflake cannot be referenced by any services within the container. This is applicable to services that exist in or outside of the app.

• Providers cannot directly share an image repository with an app. For example, providers cannot use the GRANT TO SHARE IN APPLICATION PACKAGE command.

• Providers can store multiple container images in an image repository. However, container images that are not explicitly listed in the manifest are not accessible by the app in the consumer’s account.

• When a provider adds a version definition to an application package the container images included in that version cannot be modified. The images for that version are immutable and persist throughout the life cycle of the version. To alter the containers within an app, providers must use a new version.

Upload container images to the image repository¶

After creating an image repository, providers use Docker commands to upload the container images required by the app to the image repository. The specific commands required depend on the provider’s environment. However, the general workflow is:

1. docker login

2. docker build

3. docker tag

4. docker push

The following shows a typical example of how to use these commands:

$ docker login org-provider-account.registry.snowflakecomputing.com
$ docker build --rm --platform linux/amd64 -t service:1.0 .
$ docker tag service:1.0 org-provider-account.registry.snowflakecomputing.com/provider_db/provider_schema/provider_repo/service:1.0
$ docker push org-provider-account.registry.snowflakecomputing.comprovider_db/provider_schema/provider_repo/service:1.0

Create the service specification file¶

The service specification is a YAML file that Snowpark Container Services uses to configure and run a service. See Service specification reference for general information on the syntax of this file. See Create a service from a specification file for an example of creating a service in the setup script.

The following example shows the fields in the service specification file that are required by an app with containers.

spec:
  containers:
  - image: /provider_db/provider_schema/provider_repo/server:prod
    name: server
    ...
  - image: /provider_db/provider_schema/provider_repo/web:1.0
    name: web
    ...
  endpoints:
  - name: invoke
    port: 8000
  - name: ui
    port: 5000
    public: true

Use a specifciation template¶

Providers can also use a specification template by adding a reference to a template in the service specification file:

spec:
  containers:
  - image: /provider_db/provider_schema/provider_repo/server:prod
    name: my_app_container
  endpoints:
  - name: invoke
    port: 8000
  - name: ui
    port: 5000
    public: true

See Create a service with a specification template for an example of creating a service in an app using a specification template.