I’m trying to set up an EC2 auto-scaling group that scales up based on outgoing network traffic. For some reason, the user-data I included in my Launch Configuration comes back as a Base64 string instead of a zip file on all instances created in the scaling group. I’ve never had a problem loading the wowza config via user-data when creating EC2 instances directly.
Unless I’m just missing something obvious this looks to me like an EC2 Auto Scaling bug. Are you guys aware of this issue? If so, do you know of any workaround?
I really, really don’t want to bundle my own Wowza AMI to deal with this. I like the way things are currently set up. When using the user-data approach, upgrading my custom apps & modules or the wowza ami to its latest version is a very painless process. I want to keep it this way.
I actually purchased EC2 Gold support just to figure out this issue. I’m waiting for Amazon to get back to me, but I’m not too hopeful.
I heard back from Amazon. Apparently they are very aware of this “inconsistency”, but since they have a lot of customers depending on current behavior, they won’t fix it.
It would be extremely helpful if the Wowza team could provide a patch for this. Basically, if the user-data seems to be invalid when open as a zip file, treat it as a Base64 string, decode it, and try unzipping the file again.
Right now my only solution is to either bundle my own version of the Wowza AMI, which I don’t want do since it forces me to manually maintain it with the latest version of the product, or just give up and switch to CloudFront streaming for media playback, thus getting rid of 75% of our scaling issues.
Check the XML for any problems. And the size of the file can only be 16KB I think. So if you are adding large jar files, you have to use Download tag in the Startup package startup.xml file
As far as I know, you need Elasticfox (Firefox plugin) or EC2 tools to include zipped startup package. The package is limited to 16kb. The new version of Firefox as of this writing may have broken Elasticfox.
I have the exact same issue as well. I get an unzip error when the file is downloaded. I have a startup.xml that uses the download tag to reference a startup package that is in S3.
Are startup packages supported with use of AutoScaling launch configs? What are my options? Is the suggested method to launch a default instance with a startup.xml that runs a script that copies files? I would like to update files as suggested in the EC2 guide. What was the suggestion from Charlie that solved this issue for slegay?
Check the XML for any problems. And the size of the file can only be 16KB I think. So if you are adding large jar files, you have to use Download tag in the Startup package startup.xml file
Richard
Less than that. I had a 11 KB zip file that I encoded to base64 at 15KB and was unable to create the launch configuration. By removing a 3 KB jar file and reducing the zip to 7 KB, encoding to base64 gave me a 10KB file that worked.