Terraform: Rancher Provider Support for creation of infrastructure stacks

[goffinf]

Provider: Rancher
Resource: rancher_stack

New Feature Request:

The rancher_stack resource allows creation of stacks using catalog id as an input property. However this does not appear to include entries that are defined as infrastructure templates.

Requirement: To allow an id that refers to an infrastructure template from the Rancher library catalog to be used as input to the rancher_stack resource.

[matthewhartstonge]

To clarify this request, you _can_ use the ID's from a.rancher.com:8080/api/v1-catalog/catalogs/library/templates, but currently the rancher_stack Terraform Resource creates them as a User Stack not an Infrastructure Stack.

For example, I'm wanting to get NFS binded across each Rancher Environment, but catalog_id = "library:infra*nfs:2" fails to load when under a User Stack

[saurin-ai]

I'm having the same problem. I want to terraform my Rancher environment and one of the requirements is to mount 2 volumes that will be backed by AWS EFS. I was hoping to be able to add Rancher NFS to my environment via Terraform, but am seeing that a) it appears as a User Stack which is different than when you add it via the Rancher UI and b) the nfs stack doesn't come up successfully.

[matthieudolci]

I am having the same issue and workaround it this way for now:

`data "template_file" "nfs" {
template = "${file("${path.module}/nfs.tpl")}"
vars {
nfs_mount_dir = "${var.nfs_mount_dir}"
nfs_mount_opts = "${var.nfs_mount_opts}"
nfs_nfs_server = "${lower(var.aws_region_code)}-${lower(var.aws_project_code)}-efs-${lower(var.efs_number)}.${lower(var.userdata_domain_name)}"
nfs_nfs_vers = "${var.nfs_nfs_vers}"
nfs_rancher_debug = "${var.nfs_rancher_debug}"
}
}

resource "null_resource" "template_file" {
depends_on = ["data.template_file.nfs"]
provisioner "local-exec" {
command = "echo '${data.template_file.nfs.rendered}' > nfs.txt"
}
}

resource "null_resource" "nfs" {
depends_on = ["aws_efs_mount_target.rancher","null_resource.template_file"]
provisioner "local-exec" {
command = "rancher --url ${var.rancher_server_dns_name}:${var.rancher_server_port}/v2-beta --access-key ${var.rancher_server_access_key} --secret-key ${var.rancher_server_secret_key} --env ${rancher_environment.default.id} catalog install library/nfs:${var.nfs_catalog_version} --name nfs --system -answers nfs.txt"
}
}

resource "null_resource" "delete_template_file" {
depends_on = ["null_resource.nfs"]
provisioner "local-exec" {
command = "rm nfs.txt"
}
}`

the template file:

MOUNT_DIR=${nfs_mount_dir} MOUNT_OPTS=${nfs_mount_opts} NFS_SERVER=${nfs_nfs_server} NFS_VERS=${nfs_nfs_vers} RANCHER_DEBUG=${nfs_rancher_debug}

my only issue right now is that rancher cli report an error when you try to re run the same command to create the stack

[saurin-ai]

Thanks Matthieu.

That's something I noticed as well when experimenting with this via the Rancher UI. If you deploy, then delete and re-deploy it doesn't work the 2nd time around... Not sure why, but since I'm terraforming, I'd like to be able to destroy and re-apply this particular component as needed without running into an issue.

[goffinf]

Yes the Rancher provider as it currently stands does not support use
of Infrastructure stacks nor a few other important features of the
latest version. Nonetheless it is a useful and welcome addition to
Terraform and to be fair the maintainers, they are aware. You can
always submit a pull request.

Like Matthieu we work around this by calling the Rancher CLI, but
hopefully in the future we will not need to. Our implementation is
further complicated because we are unable to resolve the EFS file
system DNS from one of our AWS VPCs, but of course that's nothing to
do with the TF provider.

Coincidentally we have Rancher on site today and will be talking about
this one so if there is any change to the way that we approach it I'll
post back here.

Regards

Fraser.

On 03/05/2017, Saurin Patel [e-mail] wrote:

Thanks Matthieu.

That's something I noticed as well when experimenting with this via the
Rancher UI. If you deploy, then delete and re-deploy it doesn't work the
2nd time around... Not sure why, but since I'm terraforming, I'd like to be
able to destroy and re-apply this particular component as needed without
running into an issue.

--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/hashicorp/terraform/issues/11771#issuecomment-298794358

[saurin-ai]

Thanks Fraser.

[matthieudolci]

Thanks @goffinf

I am trying to workaround the workaround today by using Ansible and the api, but looks like you can only get the status of a stack by is ID and not by name which makes the thing a little difficult since you will have to know the id...

[matthieudolci]

If it can help i made it work with this, not perfect still need to find more triggers and also find the way to use the api and not the cli but it is a start:

Ansible playbook

`---

• name: Deploy the NFS stack in a Rancher environment
  hosts: localhost
  become: false
  tasks:
  
  
  
  • name: Checking if the NFS stack is already started
    
    uri:
    
    url: "{{ rancher_server_dns_name }}:{{ rancher_server_port }}/v2-beta/projects/{{ rancher_environment_id }}/stacks/"
    
    return_content: yes
    
    method: GET
    
    body: "?healthState=healthy&name=nfs&state=active&externalId=catalog%3A//library%3Ainfra*nfs%3A2"
    
    headers:
    
    Content-Type: "application/json; charset=utf-8"
    
    user: "{{ rancher_server_access_key }}"
    
    password: "{{ rancher_server_secret_key }}"
    
    register: nfs
  
  

- name: Start the NFS stack
  command: rancher --url "{{ rancher_server_dns_name }}:{{ rancher_server_port }}/v2-beta" --access-key "{{ rancher_server_access_key }}" --secret-key "{{ rancher_server_secret_key }}" --env "{{ rancher_environment_id }}" catalog install library/nfs:"{{ nfs_catalog_version }}" --name "{{ stack_name }}" --system -answers "{{ file_path }}/nfs.txt"
  when: "'nfs' not in nfs.content"

`

nfs.tlp

MOUNT_DIR=${nfs_mount_dir} MOUNT_OPTS=${nfs_mount_opts} NFS_SERVER=${nfs_nfs_server} NFS_VERS=${nfs_nfs_vers} RANCHER_DEBUG=${nfs_rancher_debug}

terraform:

`# Start the NFS stack

Generate the answer file for rancher cli

data "template_file" "nfs" {
template = "${file("${path.module}/nfs.tpl")}"
vars {
nfs_mount_dir = "${var.nfs_mount_dir}"
nfs_mount_opts = "${var.nfs_mount_opts}"
nfs_nfs_server = "${lower(var.aws_region_code)}-${lower(var.aws_project_code)}-efs-${lower(var.efs_number)}.${lower(var.userdata_domain_name)}"
nfs_nfs_vers = "${var.nfs_nfs_vers}"
nfs_rancher_debug = "${var.nfs_rancher_debug}"
}
}

Create an actual file based on the answer

resource "null_resource" "template_file" {
depends_on = ["data.template_file.nfs"]
provisioner "local-exec" {
command = "echo '${data.template_file.nfs.rendered}' > nfs.txt"
}
}

Setup rancher cli and start the nfs catalog with the answer file

resource "null_resource" "start_nfs_stack" {
depends_on = ["null_resource.template_file","aws_efs_mount_target.rancher"]
provisioner "local-exec" {
command = "ansible-playbook ${path.root}/files/playbooks/rancher-nfs-stack.yml --extra-vars 'rancher_server_dns_name=${var.rancher_server_dns_name} rancher_server_port=${var.rancher_server_port} rancher_server_access_key=${var.rancher_server_access_key} rancher_server_secret_key=${var.rancher_server_secret_key} rancher_environment_id=${rancher_environment.default.id} nfs_catalog_version=${var.nfs_catalog_version} rancher_server_dns_name=${var.rancher_server_dns_name} rancher_server_port=${var.rancher_server_port} stack_name=${var.nfs_stack_name} file_path=${path.root}' "
}
triggers {
## This trigger check the checksum of the playbook and if it has been changed
## it will re-apply the start-rancher-agent resource
playbook = "${sha1(file("${path.root}/files/playbooks/rancher-nfs-stack.yml"))}"
}
}

Delete the answer file

resource "null_resource" "delete_template_file" {
depends_on = ["null_resource.start_nfs_stack"]
provisioner "local-exec" {
command = "rm nfs.txt"
}
}`

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.