Not clear whether this registers a new supplied taskdef or not

[mikebrules]

Hi,
I'm not exactly sure what is happening, and I may be misunderstanding the role of this library, but I think it is meant to register a new taskdef that you supply it (I think that because of this);

services: [
{
  taskDefinition: {
    "family": "foo" // This should already exist in ECS. Required.
  },

but then it also says "should exist" in which case am I meant to be passing a new one here or not?

I ask because the taskdef I am passing here (a JSON object) is not getting registered - the existing one is being copied and re-used. Do I need to register one myself first?

Thanks

[bradseefeld]

Hi @mikebrules! The task def should already be registered on ECS. This library will create a revision of the task def, with the only change in the new revision being the updated docker image version you are attempting to deploy.

This way, all your environment variables and other settings remain unchanged.

Let me know if that is clear. Also, if you can think of a better way to explain this in the sample/README, I am open to suggestions. :)

[mikebrules]

HI @bradseefeld thanks for getting back so soon. That explains it! I was unclear because I am frequently changing ENV VARS during dev and so I wanted a way of generating a taskdef locally and "posting" that in, which is why I thought the object structure for taskdef argument allowed me to do that. I might try and have a look at a change that would allow me to do that prior to updating the service if possible, because if I just register my new taskdef first (before calling deploy), I will end up with a new copy of that taskdef I created (so I will create twice as many as I need). Happy for me to take a look?

Thanks for your help, great lib, very useful.

[bradseefeld]

I think its fairly common to manage multiple environments using this tool. What I've seen in a couple installs so far is people build a wrapper script around this lib. That wrapper scripts manages the services attribute passed to the constructor. If they want to deploy their dev task def, they will pass the dev 'services' into the constructor and then call deploy. If they want to deploy their 'prod' task def, they do the same but with the prod services.

Feel free to take a look at what we have so far and see if you can make any improvements on top of it. If you interested in doing a PR but want to chat about the idea before committing the time, I am open to that too. Just let me know what you think.

Glad you like it!

[mikebrules]

@bradseefeld thanks. The only thing I would like to be able to do is pass my own TaskDef to the service. At the moment, it fetches one and adds the new image, but in my use case, I am creating a taskdef with all the environment variables, so rather than have it fetch one, if I could just pass my object, it would be ideal. In other words

https://github.com/DispatchBot/node-ecs-deployer/blob/master/lib/service.js#L168

could just accept the taskdef. See what I mean?

[bradseefeld]

Yes, I do. Although I want to be clear that the existing approach supports environment variables, etc too. I think I am still not fully understanding your use case regarding why you cant set the task def once in AWS. During iterative deployments, are you changing the environment variables frequently?

That said, I see the value in storing the task def locally and then pushing it up in full during a deploy. This makes any changes to env variables easier (we change these very infrequently) and also gives the person deploying more visibility into what is going out. If this is what you are trying to achieve, it would need to be an optional configuration so that we are backwards compatible with the existing method.

Also, if I can suggest on the design, I'd prefer to see the task def stored locally as a separate file, rather than embedding the task def JSON directly into the deployer config. Instead we can pass a file path/handle to the task def json file.