标签归档:heroku

如何为多个环境自定义requirements.txt?

问题:如何为多个环境自定义requirements.txt?

我有两个分支,开发和生产。每个都有依赖关系,其中一些是不同的。开发指向自身在开发中的依赖项。生产同样如此。我需要部署到Heroku,它期望每个分支的依赖性都在一个名为“ requirements.txt”的文件中。

最好的组织方式是什么?

我想到的是:

  • 维护单独的需求文件,每个分支中一个(必须在频繁合并中生存!)
  • 告诉Heroku我要使用哪个需求文件(环境变量?)
  • 编写部署脚本(创建临时分支,修改需求文件,提交,部署,删除临时分支)

I have two branches, Development and Production. Each has dependencies, some of which are different. Development points to dependencies that are themselves in development. Likewise for Production. I need to deploy to Heroku which expects each branch’s dependencies in a single file called ‘requirements.txt’.

What is the best way to organize?

What I’ve thought of:

  • Maintain separate requirements files, one in each branch (must survive frequent merges!)
  • Tell Heroku which requirements file I want to use (environment variable?)
  • Write deploy scripts (create temp branch, modify requirements file, commit, deploy, delete temp branch)

回答 0

您可以级联需求文件,并使用“ -r”标志告诉pip将一个文件的内容包含在另一个文件中。您可以将需求分解成模块化的文件夹层次结构,如下所示:

`-- django_project_root
|-- requirements
|   |-- common.txt
|   |-- dev.txt
|   `-- prod.txt
`-- requirements.txt

文件的内容如下所示:

common.txt:

# Contains requirements common to all environments
req1==1.0
req2==1.0
req3==1.0
...

dev.txt:

# Specifies only dev-specific requirements
# But imports the common ones too
-r common.txt
dev_req==1.0
...

prod.txt:

# Same for prod...
-r common.txt
prod_req==1.0
...

在Heroku之外,您现在可以设置如下环境:

pip install -r requirements/dev.txt

要么

pip install -r requirements/prod.txt

由于Heroku在项目根目录中专门查找“ requirements.txt”,因此应仅镜像prod,如下所示:

requirements.txt:

# Mirrors prod
-r requirements/prod.txt

You can cascade your requirements files and use the “-r” flag to tell pip to include the contents of one file inside another. You can break out your requirements into a modular folder hierarchy like this:

`-- django_project_root
|-- requirements
|   |-- common.txt
|   |-- dev.txt
|   `-- prod.txt
`-- requirements.txt

The files’ contents would look like this:

common.txt:

# Contains requirements common to all environments
req1==1.0
req2==1.0
req3==1.0
...

dev.txt:

# Specifies only dev-specific requirements
# But imports the common ones too
-r common.txt
dev_req==1.0
...

prod.txt:

# Same for prod...
-r common.txt
prod_req==1.0
...

Outside of Heroku, you can now setup environments like this:

pip install -r requirements/dev.txt

or

pip install -r requirements/prod.txt

Since Heroku looks specifically for “requirements.txt” at the project root, it should just mirror prod, like this:

requirements.txt:

# Mirrors prod
-r requirements/prod.txt

回答 1

今天发布原始问题和答案时不存在的可行选择是使用pipenv而不是pip管理依赖项。

使用pipenv,不再需要像pip一样手动管理两个单独的需求文件,而是通过命令行上的交互来管理开发和生产包本身。

要安装用于生产和开发的软件包:

pipenv install <package>

要仅为开发环境安装软件包:

pipenv install <package> --dev

通过这些命令,pipenv在两个文件(Pipfile和Pipfile.lock)中存储和管理环境配置。Heroku当前的Python buildpack本机支持pipenv,如果存在Pipfile.lock而不是requirements.txt,它将从Pipfile.lock进行配置。

有关该工具的完整文档,请参见pipenv链接。

A viable option today which didn’t exist when the original question and answer was posted is to use pipenv instead of pip to manage dependencies.

With pipenv, manually managing two separate requirement files like with pip is no longer necessary, and instead pipenv manages the development and production packages itself via interactions on the command line.

To install a package for use in both production and development:

pipenv install <package>

To install a package for the development environment only:

pipenv install <package> --dev

Via those commands, pipenv stores and manages the environment configuration in two files (Pipfile and Pipfile.lock). Heroku’s current Python buildpack natively supports pipenv and will configure itself from Pipfile.lock if it exists instead of requirements.txt.

See the pipenv link for full documentation of the tool.


回答 2

如果您的要求是能够在同一台计算机上的环境之间进行切换,则可能有必要为需要切换到的每个环境创建不同的virtualenv文件夹。

python3 -m venv venv_dev
source venv_dev/bin/activate
pip install -r pip/common.txt
pip install -r pip/dev.txt
exit
python3 -m venv venv_prod
source venv_prod/bin/activate
pip install -r pip/common.txt
exit
source venv_dev/bin/activate
# now we are in dev environment so your code editor and build systems will work.

# let's install a new dev package:
# pip install awesome
# pip freeze -r pip/temp.txt
# find that package, put it into pip/dev.txt
# rm pip/temp.txt

# pretty cumbersome, but it works. 

If your requirement is to be able to switch between environments on the same machine, it may be necessary to create different virtualenv folders for each environment you need to switch to.

python3 -m venv venv_dev
source venv_dev/bin/activate
pip install -r pip/common.txt
pip install -r pip/dev.txt
exit
python3 -m venv venv_prod
source venv_prod/bin/activate
pip install -r pip/common.txt
exit
source venv_dev/bin/activate
# now we are in dev environment so your code editor and build systems will work.

# let's install a new dev package:
# pip install awesome
# pip freeze -r pip/temp.txt
# find that package, put it into pip/dev.txt
# rm pip/temp.txt

# pretty cumbersome, but it works. 

在virtualenv中设置环境变量

问题:在virtualenv中设置环境变量

我有一个Heroku项目,该项目使用环境变量来获取其配置,但是我首先使用virtualenv在本地测试我的应用程序。

有没有办法在virtualenv内部设置在远程计算机上定义的环境变量?

I have a Heroku project that uses environment variables to get its configuration, but I use virtualenv to test my app locally first.

Is there a way to set the environment variables defined on the remote machine inside virtualenv?


回答 0

更新资料

截至2017年5月17日,autoenv的自述文件指出direnv可能是更好的选择,并暗示autoenv将不再维护。

旧答案

我写了autoenv来做到这一点:

https://github.com/kennethreitz/autoenv

Update

As of 17th May 2017 the README of autoenv states that direnv is probably the better option and implies autoenv is no longer maintained.

Old answer

I wrote autoenv to do exactly this:

https://github.com/kennethreitz/autoenv


回答 1

如果您使用virtualenvwrapper(我强烈建议您这样做),则可以使用中具有相同名称的脚本定义不同的钩子(预激活,后激活,预停用,后停用)$VIRTUAL_ENV/bin/。您需要后激活挂钩。

$ workon myvenv

$ cat $VIRTUAL_ENV/bin/postactivate
#!/bin/bash
# This hook is run after this virtualenv is activated.
export DJANGO_DEBUG=True
export S3_KEY=mykey
export S3_SECRET=mysecret

$ echo $DJANGO_DEBUG
True

如果要将此配置保留在项目目录中,只需创建一个从项目目录到的符号链接$VIRTUAL_ENV/bin/postactivate

$ rm $VIRTUAL_ENV/bin/postactivate
$ ln -s .env/postactivate $VIRTUAL_ENV/bin/postactivate

您甚至可以在每次使用mkvirtualenv自动创建符号链接

清除后停用

请记住,这本身不会清除。停用virtualenv时,环境变量将保留。要对称清理,您可以添加到$VIRTUAL_ENV/bin/predeactivate

$ cat $VIRTUAL_ENV/bin/predeactivate
#!/bin/bash
# This hook is run before this virtualenv is deactivated.
unset DJANGO_DEBUG

$ deactivate

$ echo $DJANGO_DEBUG

请记住,如果将其用于可能已在您的环境中设置的环境变量,则取消设置将导致它们在离开virtualenv时被完全取消设置。因此,如果完全有可能,您可以将先前的值记录在临时位置,然后在停用时重新读回。

建立:

$ cat $VIRTUAL_ENV/bin/postactivate
#!/bin/bash
# This hook is run after this virtualenv is activated.
if [[ -n $SOME_VAR ]]
then
    export SOME_VAR_BACKUP=$SOME_VAR
fi
export SOME_VAR=apple

$ cat $VIRTUAL_ENV/bin/predeactivate
#!/bin/bash
# This hook is run before this virtualenv is deactivated.
if [[ -n $SOME_VAR_BACKUP ]]
then
    export SOME_VAR=$SOME_VAR_BACKUP
    unset SOME_VAR_BACKUP
else
    unset SOME_VAR
fi

测试:

$ echo $SOME_VAR
banana

$ workon myenv

$ echo $SOME_VAR
apple

$ deactivate

$ echo $SOME_VAR
banana

In case you’re using virtualenvwrapper (I highly recommend doing so), you can define different hooks (preactivate, postactivate, predeactivate, postdeactivate) using the scripts with the same names in $VIRTUAL_ENV/bin/. You need the postactivate hook.

$ workon myvenv

$ cat $VIRTUAL_ENV/bin/postactivate
#!/bin/bash
# This hook is run after this virtualenv is activated.
export DJANGO_DEBUG=True
export S3_KEY=mykey
export S3_SECRET=mysecret

$ echo $DJANGO_DEBUG
True

If you want to keep this configuration in your project directory, simply create a symlink from your project directory to $VIRTUAL_ENV/bin/postactivate.

$ rm $VIRTUAL_ENV/bin/postactivate
$ ln -s .env/postactivate $VIRTUAL_ENV/bin/postactivate

You could even automate the creation of the symlinks each time you use mkvirtualenv.

Cleaning up on deactivate

Remember that this wont clean up after itself. When you deactivate the virtualenv, the environment variable will persist. To clean up symmetrically you can add to $VIRTUAL_ENV/bin/predeactivate.

$ cat $VIRTUAL_ENV/bin/predeactivate
#!/bin/bash
# This hook is run before this virtualenv is deactivated.
unset DJANGO_DEBUG

$ deactivate

$ echo $DJANGO_DEBUG

Remember that if using this for environment variables that might already be set in your environment then the unset will result in them being completely unset on leaving the virtualenv. So if that is at all probable you could record the previous value somewhere temporary then read it back in on deactivate.

Setup:

$ cat $VIRTUAL_ENV/bin/postactivate
#!/bin/bash
# This hook is run after this virtualenv is activated.
if [[ -n $SOME_VAR ]]
then
    export SOME_VAR_BACKUP=$SOME_VAR
fi
export SOME_VAR=apple

$ cat $VIRTUAL_ENV/bin/predeactivate
#!/bin/bash
# This hook is run before this virtualenv is deactivated.
if [[ -n $SOME_VAR_BACKUP ]]
then
    export SOME_VAR=$SOME_VAR_BACKUP
    unset SOME_VAR_BACKUP
else
    unset SOME_VAR
fi

Test:

$ echo $SOME_VAR
banana

$ workon myenv

$ echo $SOME_VAR
apple

$ deactivate

$ echo $SOME_VAR
banana

回答 2

您可以尝试:

export ENVVAR=value

在virtualenv_root / bin / activate中。基本上,激活脚本是您开始使用virtualenv时执行的脚本,因此您可以在其中放置所有自定义内容。

You could try:

export ENVVAR=value

in virtualenv_root/bin/activate. Basically the activate script is what is executed when you start using the virtualenv so you can put all your customization in there.


回答 3

仅使用virtualenv(不使用virtualenvwrapper),通过activate您采购的用于激活virtualenv 的脚本即可轻松设置环境变量。

跑:

nano YOUR_ENV/bin/activate

将环境变量添加到文件末尾,如下所示:

export KEY=VALUE

如果需要,您还可以设置类似的钩子来取消设置环境变量,如Danilo Bargen在上面的出色答案中所建议的那样。

Using only virtualenv (without virtualenvwrapper), setting environment variables is easy through the activate script you sourcing in order to activate the virtualenv.

Run:

nano YOUR_ENV/bin/activate

Add the environment variables to the end of the file like this:

export KEY=VALUE

You can also set a similar hook to unset the environment variable as suggested by Danilo Bargen in his great answer above if you need.


回答 4

尽管这里有很多不错的答案,但我没有看到一个发布的解决方案,该解决方案既包括在停用时取消设置环境变量,又不需要除之外的其他库virtualenv,因此这是我的解决方案,仅涉及使用/ bin / activate进行编辑。变量MY_SERVER_NAMEMY_DATABASE_URL示例:

在激活脚本中应该有一个用于停用的定义,并且您想在其末尾取消设置变量:

deactivate () {
    ...

    # Unset My Server's variables
    unset MY_SERVER_NAME
    unset MY_DATABASE_URL
}

然后在激活脚本的末尾,设置变量:

# Set My Server's variables
export MY_SERVER_NAME="<domain for My Server>"
export MY_DATABASE_URL="<url for database>"

这样,您无需安装其他任何东西即可使它正常工作,并且最终不会在您deactivate使用virtualenv 时留下变量。

While there are a lot of nice answers here, I didn’t see a solution posted that both includes unsetting environment variables on deactivate and doesn’t require additional libraries beyond virtualenv, so here’s my solution that just involves editing /bin/activate, using the variables MY_SERVER_NAME and MY_DATABASE_URL as examples:

There should be a definition for deactivate in the activate script, and you want to unset your variables at the end of it:

deactivate () {
    ...

    # Unset My Server's variables
    unset MY_SERVER_NAME
    unset MY_DATABASE_URL
}

Then at the end of the activate script, set the variables:

# Set My Server's variables
export MY_SERVER_NAME="<domain for My Server>"
export MY_DATABASE_URL="<url for database>"

This way you don’t have to install anything else to get it working, and you don’t end up with the variables being left over when you deactivate the virtualenv.


回答 5

在virtualenv内部,可以使用两种方法进行测试。第一个是通过Heroku工具栏(https://toolbelt.heroku.com/)安装的工具。该工具是领班。它将导出本地存储在.env文件中的所有环境变量,然后在Procfile中运行应用程序进程。

如果您正在寻找一种更简单的方法,第二种方法是在本地拥有一个.env文件,然后运行:

export $(cat .env)

Locally within an virtualenv there are two methods you could use to test this. The first is a tool which is installed via the Heroku toolbelt (https://toolbelt.heroku.com/). The tool is foreman. It will export all of your environment variables that are stored in a .env file locally and then run app processes within your Procfile.

The second way if you’re looking for a lighter approach is to have a .env file locally then run:

export $(cat .env)

回答 6

安装autoenv或者通过

$ pip install autoenv

(要么)

$ brew install autoenv

然后.env在您的virtualenv项目文件夹中创建文件

$ echo "source bin/activate" > .env

现在一切正常。

Install autoenv either by

$ pip install autoenv

(or)

$ brew install autoenv

And then create .env file in your virtualenv project folder

$ echo "source bin/activate" > .env

Now everything works fine.


回答 7

如果您已经在使用Heroku,请考虑通过Foreman运行服务器。它支持一个.env仅是行列表的文件,该文件KEY=VAL将在运行前导出到您的应用。

If you’re already using Heroku, consider running your server via Foreman. It supports a .env file which is simply a list of lines with KEY=VAL that will be exported to your app before it runs.


回答 8

另一种为django设计的方法,但应该在大多数设置中都可以使用,那就是使用django-dotenv。

Another way to do it that’s designed for django, but should work in most settings, is to use django-dotenv.


回答 9

要在env目录中激活virtualenv 并导出.env使用中存储的环境变量:

source env/bin/activate && set -a; source .env; set +a

To activate virtualenv in env directory and export envinroment variables stored in .env use :

source env/bin/activate && set -a; source .env; set +a

Caprover 可扩展的PaaS(自动Docker+nginx)

CapRover

适用于NodeJS、Python、PHP、Ruby、Go应用程序的最简单的应用程序/数据库部署平台和Web服务器软件包

不需要码头工人,nginx知识!



这是什么?

CapRover是一款极其易于使用的应用程序/数据库部署和Web服务器管理器,适用于NodeJS、Python、PHP、ASP.NET、Ruby、MySQL、MongoDB、Postgres、WordPress(等等)申请!

它的速度非常快,而且非常健壮,因为它在其简单易用的界面背后使用了Docker、nginx、LetsEncrypt和NetData

✔用于自动化和脚本编写的CLI

✔便于访问和方便的Web GUI

✔不能锁定!删除CapRover,您的应用程序将继续工作!

✔引擎盖下的码头工人蜂拥而至,进行集装箱化和集群化

✔Nginx(完全可定制的模板)在引擎盖下,用于负载均衡

✔让我们在幕后加密以获得免费的SSL(HTTPS)

我是认真的!谁应该关心CapRover?

  • 不喜欢花费数小时和数天时间设置服务器、构建工具、向服务器发送代码、构建服务器、获取SSL证书、安装证书、反复更新nginx的[web]开发人员
  • 开发人员使用昂贵的服务,如Heroku、Microsoft Azure等,并希望将其成本降低到原来的1/4(Heroku对其1 GB实例每月收费25美元,而同一服务器在Valltr上的收费是5美元!)
  • 喜欢写更多关于showResults(getUserList())而且不是很多$ apt-get install libstdc++6 > /dev/null
  • 喜欢在服务器上安装MySQL、MongoDB等的开发人员,方法是从下拉菜单中选择并单击Install!
  • 设置CapRover服务器需要多少服务器/坞站/Linux知识?答:复制粘贴知识!!有关要复制和粘贴的内容的信息,请转到“入门”;-)

了解更多信息!

有关更多详细信息和文档,请访问https://CapRover.com/

贡献者

这个项目的存在要归功于所有做出贡献的人。[Contribute]

支持者

感谢我们所有的支持者!🙏