Maybe it's the benefit of writing an app with over a gig of data to put in place and process when building, but I have been able to piece together something that hopefully someone else finds helpful. When you deploy your latest code, it gets extracted to /var/app/staging and then all of your .ebextensions commands run on that directory and when it's done, it moves it to /var/app/current.
So why is this important? Well, as you start to add your own .ebextensions setup scripts, you have to keep your paths relative to the app. The gig of data I was talking about was a zip file of some image files necessary for the app. The zip file was downloaded to the /tmp directory and then I was running unzip /tmp/file.zip /var/app/current/path/to/images. This would work, but it was unzipping the image files into the current app vs. what's about to be deployed. So after the deployment was done, the /var/app/staging/path/to/images was empty and then became /var/app/current/path/to/images. Then I was left wondering where my images were! So when you run commands that affect the filesystem, specify the paths relative to your project or app root. So that means it would look something like this: unzip /tmp/file.zip path/to/images.
I should also mention that if you have directories that are setup in particular ways, like permissions or ownership, you'll need to do that relative to the project or app root as well. We have a folder that we put uploaded files in from the public, so that needs to be owned by the webapp and world-writable. So those folders need to be handled the same way from your .ebextensions folder and relatively from the project root like so: chmod -R a+rw path/to/uploads.
Top comments (0)