In your quest to convert all of the older infrastructure for the Pulumipus Boba Tea Shop to Pulumi, you realized that you have some resources that are deployed using the old system. Rather than spinning those resources back up when you deploy your Pulumi program, you just want to import the state of those resources into Pulumi. While it may seem like a contrived example, it's actually a very common situation. Other teams or prior work used tools like Ansible, a CDK, or Terraform or chose to build and manage infrastructure by hand through CLIs from the cloud providers or through the web portals and UIs from various providers. Migrating to a platform like Pulumi that manages state requires either (1) replacing those resources or (2) finding a way to tell the platform about the resource's current state and tying that resource to code udpates in the future. Generally, unless a platform replaces resources regularly, it's less disruptive and more useful to leave those resources standing when moving to Pulumi.
For Pulumi, there are three paths to take when importing resources. Pulumi allows you to import resources from any currently existing system with either (1) the `import` CLI command or (2) an `import` option in the code. Alternately, we can bulk import resources from anywhere with a special JSON file and the `import` CLI command. The CLI command also offers a resource definition (code snippet) that we can add to our Pulumi program to manage the resource moving forward. Because of this bonus information, we'll explore the CLI command first.
## Setting up
The `pulumi import` command is built into the CLI, so there's nothing new to install there. However, there *are* some setup steps we need to do. First, we need to create a Pulumi project and stack for the resource to live in.
```bash
$ mkdir learn-pulumi-import
$ cd learn-pulumi-import
$ pulumi new <language> -y
```
For the provider that currently hosts that resource, we need to follow the installation and configuration information for the provider. So, for Docker, we're following [these directions].
Since you're using YAML, there's no specific setup. We'll add the provider as part of our updates to the `Pulumi.yaml` file.
{{% /choosable %}}
{{</chooser>}}
## Using the `import` command
Now that we have our provider set up, we can import some resources! We're going to import a `Container` resource. The first thing we have to do is figure out the **type**, **name**, and **ID** of the resource we want to import. Resources that are importable all have [a section in the API docs] that demonstrates these values. Note that, in general, the resources in a generally available provider can be imported. If it's a provider in public preview (as noted in the API docs), those resources cannot be imported yet as the maintainers are focusing on general features before moving to imports.
In the case of the Docker provider's `Container` resource, here's the sample:
We can work with this! The _type_ will be the same regardless of which container we import as that type defines the resource type that Pulumi searches for. To break it down, it's of a form of `<provider>:<namespace>:<resource>`, so we're using the `docker` provider, searching in the `index/container` namespace, and wanting the `Container` resource.
To get the _name_ and _id_, we're going to ask Docker for that information:
```bash
$ docker ps -a --no-trunc
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0dcb71164c20edb491477f16028f34546bc7852351c442bab4998a015b41cfba sha256:f62880b6243361e97fc9dd5ee4def8a1bc4fd0e44b1b93660157b24b628dbe23 "docker-entrypoint.sh npm start" 10 minutes ago Up 10 minutes 0.0.0.0:3001->3001/tcp frontend-dev
a4087dbaaaa3ef75ca69fa0b871f3c9a94e5fc963ff13f62246b97bc75e20fc0 sha256:bbf5d2ba61771bdbb5208366d85e7fec004082826069f26376ebd1f8b850d2a2 "docker-entrypoint.sh npm start" 10 minutes ago Up 10 minutes 0.0.0.0:3000->3000/tcp backend-dev
d9c6afa03e5b0862c2368e3578cfb820df4caf8f9e4341df789fdd2c0e53081a sha256:8c7e1d287856ec812667ffb046d78b2250b35c1c2119e9e3fddb09633bcd4982 "docker-entrypoint.sh mongod" 11 minutes ago Up 11 minutes (healthy) 0.0.0.0:27017->27017/tcp mongo-dev
```
So, for the first container in the list, _name_ is `frontend-dev` and _id_ is `0dcb71164c20edb491477f16028f34546bc7852351c442bab4998a015b41cfba`. Let's try importing that resource! Run the following command:
Notice the equal sign (=) instead of our usual plus sign (+) in the resource table and in the details? That's Pulumi's way of telling us that it's adding something to the state without modifying it. In short, it's the import sign.
And when we actually say yes to the import, here's the output:
Notice you'll get a code snippet (or resource definition) to add to your {{<langfile>}}.
{{% notes type="info" %}}
One thing to note here is the `protect` option (documented [in the TypeScript SDK] and [in the Python SDK]). Because we're importing this resource into state without it being in the code, the resource is protected from accidental deletion on a `pulumi destroy` to avoid tearing down a resource before the code for it has been completed. To delete the resource, you have to set that flag to `false` through the code.
[in the TypeScript SDK]: https://www.pulumi.com/docs/reference/pkg/nodejs/pulumi/pulumi/#ResourceOptions-protect
[in the Python SDK]: https://www.pulumi.com/docs/reference/pkg/python/pulumi/#pulumi.ResourceOptions
{{% /notes %}}
Generally, the code snippets are reasonably helpful. In this case, however, the code snippet provided will need to be modified as the container information is all stored in the image rather than the container. Usually, the main changes to these code snippets are to use resource references and update any variables we plan to provide, along with merging it into existing Pulumi programs.
