如何阻止弹性魔豆(显然)删除我下载的文件? [英] How do I stop Elastic Beanstalk (apparently) removing my downloaded file?
问题描述
我在一个.ebextensions config文件,这些容器的命令:
I have these container commands in an .ebextensions .config file:
container_commands:
download_geography_data_01:
command: "python scripts/download_geography_data.py"
download_geography_data_02:
command: "file /opt/python/current/app/data/geography/geography.sqlite"
和这些执行完全当我使用 EB创建
- 第二个命令就在那里把日志中证明了第一个脚本运行正确的条目和文件是创建。我得到这样的eb_activity.log一条线,那正是我所期望的:
And these execute perfectly when I use eb create
- the second command is just there to put an entry in the log proving that the first script ran correctly and the file was created. I get a line like this in eb_activity.log, exactly as I would expect:
完成的活动。结果:/opt/python/current/app/data/geography/geography.sqlite:3.X的SQLite数据库
但2分钟后,它有我的Python的Web服务器应用程序的启动和运行,当它试图读取该文件,它失败:
But 2 minutes later, it has my Python web server app is up and running and when it attempts to read that file, it fails:
IO错误:没有找到地理数据文件。路径搜索是/opt/python/current/app/data/geography/geography.sqlite
我然后用 EB SSH
登录我的环境,这是正确的 - 该文件是不存在的。它看似配置阶段和执行阶段之间消失了。
I then use eb ssh
to log in to my environment, and it's right - the file is not there at all. It has seemingly disappeared between the configuration stage and the execution stage.
任何人有任何想法可能是什么问题呢?难道不知何故被清除这个文件了吗?
Anybody have any idea what could be going wrong? Could it somehow be clearing this file away?
我使用的64位亚马逊的Linux 2015.03 1.4.3运行的Python 2.7的平台,如果是相关的。
I'm using the "64bit Amazon Linux 2015.03 v1.4.3 running Python 2.7" platform, if that is relevant.
推荐答案
AWS弹性魔豆有永远删除你的文件,除了app目录。
AWS Elastic Beanstalk have never removed your file, except for the app directory.
由于AWS文档中<一说href="http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-containers-ec2.html#customize-containers-format-container_commands"相对=nofollow>在Linux服务器定制软件的:
您可以使用 container_commands
键为您的容器执行命令。在 container_commands命令
的按字母顺序排列的名称进行处理。 它们运行后,应用程序和Web服务器已经设置了和应用程序版本的文件已被提取,但应用程序版本部署之前。他们还可以使用环境变量,例如您的AWS安全证书。此外,还可以使用 leader_only
。一个实例是选择成为领导者在自动缩放组。如果 leader_only
值设置为真
,运行该命令只能在被标记为组长的实例。
You can use the
container_commands
key to execute commands for your container. The commands incontainer_commands
are processed in alphabetical order by name. They run after the application and web server have been set up and the application version file has been extracted, but before the application version is deployed. They also have access to environment variables such as your AWS security credentials. Additionally, you can useleader_only
. One instance is chosen to be the leader in an Auto Scaling group. If theleader_only
value is set totrue
, the command runs only on the instance that is marked as the leader.
您把您的SQLite数据库您的应用程序目录中。当你升级到一个新的,你进入你的旧目录将被销毁。
You put your SQLite database inside your app directory. When you update to a new one, your change into your old directory will be destroyed.
在部署:
[ec2-user@ip-172-31-52-184 python]$ ll /opt/python/
total 20
drwxr-xr-x 2 root root 4096 Jul 30 09:09 bin
drwxr-xr-x 3 root root 4096 Jul 30 09:12 bundle
lrwxrwxrwx 1 root root 20 Jul 30 09:12 current -> /opt/python/bundle/3
drwxr-xr-x 2 root root 4096 Jul 30 09:09 etc
drwxrwxr-x 3 root wsgi 4096 Jul 30 09:10 log
drwxr-xr-x 4 root root 4096 Jul 30 09:10 run
在部署:
[ec2-user@ip-172-31-52-184 python]$ ll /opt/python/
total 20
drwxr-xr-x 2 root root 4096 Jul 30 09:09 bin
drwxr-xr-x 4 root root 4096 Jul 30 09:18 bundle
lrwxrwxrwx 1 root root 20 Jul 30 09:12 current -> /opt/python/bundle/3
drwxr-xr-x 2 root root 4096 Jul 30 09:09 etc
drwxrwxr-x 3 root wsgi 4096 Jul 30 09:10 log
lrwxrwxrwx 1 root root 20 Jul 30 09:18 ondeck -> /opt/python/bundle/4
部署后:
[ec2-user@ip-172-31-52-184 python]$ ll /opt/python/
total 20
drwxr-xr-x 2 root root 4096 Jul 30 09:09 bin
drwxr-xr-x 3 root root 4096 Jul 30 09:18 bundle
lrwxrwxrwx 1 root root 20 Jul 30 09:18 current -> /opt/python/bundle/4
drwxr-xr-x 2 root root 4096 Jul 30 09:09 etc
drwxrwxr-x 3 root wsgi 4096 Jul 30 09:10 log
drwxr-xr-x 4 root root 4096 Jul 30 09:10 run
你是否注意到你的的/ opt /蟒蛇/电流/应用程序
改变?虽然有关部署,你的的/ opt /蟒蛇/电流/应用程序
是指向的/ opt /蟒蛇/捆/ 3
。再部署之后,它指向的/ opt /蟒蛇/捆绑/ 4
。然后,在的/ opt /蟒蛇/捆/ 3
(旧的应用程序)将被删除。
Do you notice your /opt/python/current/app
changed? While on deploying, your /opt/python/current/app
is pointed to /opt/python/bundle/3
. And then after deployed, it is pointed to /opt/python/bundle/4
. And then, the /opt/python/bundle/3
(your old app) is removed.
因此,该解决方案可能是:
So, the solution might be:
- 请不要把你的数据库,你的应用程序目录中。只要把你的应用程序目录以外的任何位置。
- 运行部署后命令(见这里)。
更新的:第一次部署和首次更新的
TLDR:如果您创建一个新的环境,在的/ opt /蟒蛇/电流
指出,以的/ opt /蟒蛇/捆/ 1
,然后它会被更新,以的/ opt /蟒蛇/捆/ 2
。所以,在你的应用程序部署,有实例中默认应用程序。
TLDR: If you create a new environment, the /opt/python/current
was pointed to /opt/python/bundle/1
and then it will be updated to /opt/python/bundle/2
. So, before your app is deployed, there is a "default" app inside the instance.
我创建了一个简单的 .ebextensions
脚本列出里面的所有对象的/ opt /蟒蛇
:
I create a simple .ebextensions
script to list all object inside /opt/python
:
.ebextensions / ENV-check.config
files:
"/opt/env-checker/env-checker.sh" :
content : |
#!/usr/bin/env bash
TIMESTAMP=`date +%Y%m%d_%H%M%S_%N`
if [ -d /opt/python ]
then
echo "PWD: $PWD" >> /opt/env-checker/${TIMESTAMP}_${1}
ls -al /opt/python >> /opt/env-checker/${TIMESTAMP}_${1}
else
echo "PWD: $PWD" >> /opt/env-checker/${TIMESTAMP}_${1}
ls -al /opt >> /opt/env-checker/${TIMESTAMP}_${1}
fi
mode : "000755"
owner : root
group : root
"/opt/elasticbeanstalk/hooks/appdeploy/post/post-check.sh":
mode: "000755"
owner: root
group: root
content: |
#!/usr/bin/env bash
/opt/env-checker/env-checker.sh 02_post_deploy
commands:
000_create_post_dir:
command: "mkdir /opt/elasticbeanstalk/hooks/appdeploy/post"
ignoreErrors: true
100_commands_envc:
command: /opt/env-checker/env-checker.sh 00_commands
container_commands:
101_container_commands_envc:
command: /opt/env-checker/env-checker.sh 01_container_commands
在首次部署(通过创建一个新的环境,上述 .ebentensions
),我得到这样的:
In the first deployment (create a new environment using the above .ebentensions
), I got this:
20150730_141343_068692315_00_commands
PWD: /
total 28
drwxr-xr-x 7 root root 4096 Jul 30 14:13 .
drwxr-xr-x 6 root root 4096 Jul 30 14:13 ..
drwxr-xr-x 2 root root 4096 Jul 30 14:13 bin
drwxr-xr-x 3 root root 4096 Jul 30 14:13 bundle
lrwxrwxrwx 1 root root 20 Jul 30 14:13 current -> /opt/python/bundle/1
drwxr-xr-x 2 root root 4096 Jul 30 14:13 etc
drwxrwxr-x 3 root wsgi 4096 Jul 30 14:13 log
drwxr-xr-x 4 root root 4096 Jul 30 14:13 run
20150730_141350_596104854_01_container_commands
PWD: /opt/python/bundle/2/app
total 28
drwxr-xr-x 7 root root 4096 Jul 30 14:13 .
drwxr-xr-x 6 root root 4096 Jul 30 14:13 ..
drwxr-xr-x 2 root root 4096 Jul 30 14:13 bin
drwxr-xr-x 4 root root 4096 Jul 30 14:13 bundle
lrwxrwxrwx 1 root root 20 Jul 30 14:13 current -> /opt/python/bundle/1
drwxr-xr-x 2 root root 4096 Jul 30 14:13 etc
drwxrwxr-x 3 root wsgi 4096 Jul 30 14:13 log
lrwxrwxrwx 1 root root 20 Jul 30 14:13 ondeck -> /opt/python/bundle/2
drwxr-xr-x 4 root root 4096 Jul 30 14:13 run
20150730_141355_731024404_02_post_deploy
PWD: /
total 28
drwxr-xr-x 7 root root 4096 Jul 30 14:13 .
drwxr-xr-x 6 root root 4096 Jul 30 14:13 ..
drwxr-xr-x 2 root root 4096 Jul 30 14:13 bin
drwxr-xr-x 3 root root 4096 Jul 30 14:13 bundle
lrwxrwxrwx 1 root root 20 Jul 30 14:13 current -> /opt/python/bundle/2
drwxr-xr-x 2 root root 4096 Jul 30 14:13 etc
drwxrwxr-x 3 root wsgi 4096 Jul 30 14:13 log
drwxr-xr-x 4 root root 4096 Jul 30 14:13 run
在第二次部署(第一次更新),我得到这样的:
In the second deployment (first update), I got this:
20150730_141535_631911395_00_commands
PWD: /
total 28
drwxr-xr-x 7 root root 4096 Jul 30 14:13 .
drwxr-xr-x 6 root root 4096 Jul 30 14:13 ..
drwxr-xr-x 2 root root 4096 Jul 30 14:13 bin
drwxr-xr-x 3 root root 4096 Jul 30 14:13 bundle
lrwxrwxrwx 1 root root 20 Jul 30 14:13 current -> /opt/python/bundle/2
drwxr-xr-x 2 root root 4096 Jul 30 14:13 etc
drwxrwxr-x 3 root wsgi 4096 Jul 30 14:13 log
drwxr-xr-x 4 root root 4096 Jul 30 14:13 run
20150730_141542_258594223_01_container_commands
PWD: /opt/python/bundle/3/app
total 28
drwxr-xr-x 7 root root 4096 Jul 30 14:15 .
drwxr-xr-x 6 root root 4096 Jul 30 14:13 ..
drwxr-xr-x 2 root root 4096 Jul 30 14:13 bin
drwxr-xr-x 4 root root 4096 Jul 30 14:15 bundle
lrwxrwxrwx 1 root root 20 Jul 30 14:13 current -> /opt/python/bundle/2
drwxr-xr-x 2 root root 4096 Jul 30 14:13 etc
drwxrwxr-x 3 root wsgi 4096 Jul 30 14:13 log
lrwxrwxrwx 1 root root 20 Jul 30 14:15 ondeck -> /opt/python/bundle/3
drwxr-xr-x 4 root root 4096 Jul 30 14:13 run
20150730_141547_336930605_02_post_deploy
PWD: /
total 28
drwxr-xr-x 7 root root 4096 Jul 30 14:15 .
drwxr-xr-x 6 root root 4096 Jul 30 14:13 ..
drwxr-xr-x 2 root root 4096 Jul 30 14:13 bin
drwxr-xr-x 3 root root 4096 Jul 30 14:15 bundle
lrwxrwxrwx 1 root root 20 Jul 30 14:15 current -> /opt/python/bundle/3
drwxr-xr-x 2 root root 4096 Jul 30 14:13 etc
drwxrwxr-x 3 root wsgi 4096 Jul 30 14:13 log
drwxr-xr-x 4 root root 4096 Jul 30 14:13 run
从上述结果和EC2实例里面的一些检查,我可以得出这样的结论:
From the above result and some checking inside EC2 instance, I can conclude that:
- 有默认的应用程序
的/ opt /蟒蛇/捆/ 1
您的应用程序之前目录进入的/ opt /蟒蛇
。
在你的应用程序文件在 - 的
命令
在.ebextensions
将被执行OPT /蟒蛇 -
的工作目录命令
是/
。
后您的应用程序文件被提取 - 的
container_commands
在.ebextensions
将被执行/选择/蟒蛇 -
container_commands
的工作目录是在你的最新的应用程序目录中的的/ opt /蟒蛇
。 - 在EB将删除旧的应用程序目录中的应用程序部署之后。
/
。
。
- There is default app
/opt/python/bundle/1
directory before your app come into/opt/python
. - The
commands
in.ebextensions
will be executed before your app file is in/opt/python
. - The working directory of
commands
is in/
. - The
container_commands
in.ebextensions
will be executed after your app file is extracted in/opt/python
. - The working directory of
container_commands
is in your latest app directory in/opt/python
. - EB will remove your old app directory after the app is deployed.
我想,另一种解决办法:你可以使用你的脚本的当前工作目录下把你的SQLite数据库
I thought, another solution: you can put your SQLite database using current working directory of your script.
这篇关于如何阻止弹性魔豆(显然)删除我下载的文件?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!