Modify getting-started to use devmapper snapshottter

[IRCody]

Signed-off-by: Cody Roseborough [email protected]

Issue #, if available: #194

Description of changes:
Modifies the getting started guide to use dev-mapper snapshotter instead of the naive snapshotter.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[mxpv]

We should mention that this kind of configuration is slow, should be avoided in production and suitable only for local testing. https://docs.docker.com/storage/storagedriver/device-mapper-driver/#performance-best-practices

[IRCody]

We should mention that this kind of configuration is slow, should be avoided in production and suitable only for local testing. https://docs.docker.com/storage/storagedriver/device-mapper-driver/#performance-best-practices

Do you think a Note: This is not a production ready configuration, see link is enough or do you think it might be worth saying more?

[kzys]

containerd 1.3 is already having the devmapper snapshotter. Don't we want to use the upstream one instead of our plugin one?

[mxpv]

Do you think a Note: This is not a production ready configuration, see link is enough or do you think it might be worth saying more?

May be something like: Note: the configuration with loopback devices is slow and not intended for use in production ?

containerd 1.3 is already having the devmapper snapshotter. Don't we want to use the upstream one instead of our plugin one?

Yeah. We should start this transition. But I don't think it has be done here as this PR focuses on thin-pool creation. I've created an issue to track: #318

[mxpv]

LGTM