Create ecr_registry resource to login to ecr

[chrisferry]

Referencing https://github.com/chef-cookbooks/docker/issues/660 To access docker images in ECR we need to login using awscli. See https://gist.github.com/chrisferry/f716d3e74d534598eaa5 for an example.

[rashidmahmood]

@chrisferry Can you please explain how to use this "https://gist.github.com/chrisferry/f716d3e74d534598eaa5 " ?

[rashidmahmood]

Here is a workaround for this issue.

1. Setup your access keys to your node.
2. Add this to your recipe. It will simply login to ECR.
   cmd = "aws ecr get-login --region us-east-1" value = #{cmd} list = value.split(" ")

docker_registry 'AWS ECR registry' do serveraddress 'https://xyz.ecr.us-east-1.amazonaws.com' username 'AWS' password "#{list[5]}" email 'none' end

[don-code]

I'd like to begin work on this feature (have a dire use case for it), but it would require the aws cookbook to depend on the docker cookbook to implement fully. In the interest of keeping aws lightweight, I'm thinking of creating a separate aws_ecr cookbook with nothing but an aws_ecr_registry LWRP, but will defer that decision to this cookbook's maintainers.

[petewilcock]

+1 to this. Staggering that Chef has no native resource to be able to log into ECR. What year is this?

[turtleDev]

@petewilcock 2018 apparently.

[charlieoleary]

@turtleDev Greetings from 2019.

[scalp42]

Are you all blocked or you just want a Chef resource?

If blocked, I don't mind providing the way to do it.

Ping me and I'll post solution here 👨‍🍳

[turtleDev]

@rashidmahmood already demonstrated how to work around the issue.

But here's the thing, the cookbook should already provide a resource for ECR, since that's the 'proper' way of doing it.

[scalp42]

@turtleDev I don't think it's a good workaround as you refresh the token within the valid interval for no reason as well as having the username hardcoded (creds are base64 encoded with the username inside).

But sure if it works 🤷‍♂

[charlieoleary]

The username for the ECR login never changes as far as I’m aware, so there’s no huge issue with it being hard-coded. As far as refreshing the token, since it’s only valid for a relatively short amount of time (compared to the standard Docker login), you should probably just refresh it when your client runs to avoid any pitfalls.

Either way, the other solutions seemed to be missing things or weren’t as flexible as I’d hoped. I ended up writing a quick recipe that works with the Docker cookbook and allows me to login during the run. I’ll share the gist if anyone wants to use it. It’s pretty adaptable and could be converted into a resource.

[scalp42]

Have a look at: https://github.com/awslabs/amazon-ecr-credential-helper

[turtleDev]

@scalp42

don't think it's a good workaround as you refresh the token within the valid interval for no reason as well as having the username hardcoded (creds are base64 encoded with the username inside).

I totally agree.

But rather than having another workaround, I'd rather have a resource to work with.

That said, I think it's a good idea for you to post your work around here anyway, if you think it solves the problem better than the current fix. It maybe useful for other people who ran into the same problem as the rest of us.

[charlieoleary]

@scalp42 Ah, that's a great callout, actually, and a much better solution. I always forget about the credential helper (despite using it elsewhere).

[scalp42]

@charlieoleary I think so too as well.

• install golang
• download or install the helper with the go get
• use a file resource in Chef with target /root/.docker/config.json
• dump the content of a hash of attributes for your registries (repositories if ECR) with JSON.dump:

  file '/root/.docker/config.json' do
  			content JSON.pretty_generate(node['my_registries'].to_h, quirks_mode: true)
  end
  

• hint: you might want to read the content of /root/.docker/config.json first and then deep merge your attributes to be safe

Bonus point is that you can also have ECR, Quay.io etc working at the same time in the my_registries hash and decide if you want to turn a provider on/off with a feature flag:

if node[cookbook_name][recipe_name]['my_registries']['quay']['enabled']
  current_config['auths']['quay.io'] = { 
			'auth' => ::MyLib::KMS.decrypt(node[cookbook_name][recipe_name]['my_registries']['quay']['auth']) 
										}
else
  current_config['auths'].delete('quay.io')
end

I just don't think registries auth have much to do with Chef resources to be transparent but if it works for you 🤷‍♂

cc @turtleDev

[charlieoleary]

Yeah, totally. The previous use case was to avoid persisting a DockerHub / Quay / whatever login on each instance for anyone to use and making that only available to Chef. The docker cookbook made this workable with the docker_registry resource. This is less of an issue with ECR since it’s handled with IAM roles, so the logins can be handled in a much more flexible manner.