<commit_before>---
title: Python on Docker
weight: 48
tags:
  - python
  - languages
  - docker
categories:
  - docker-integration
---
In this article you will learn about setting up a Python based project on our Docker infrastructure. We will use [nosetest](https://nose.readthedocs.org/en/latest/) and [py.test](http://pytest.org/latest/) for setting up the build, but the same works for any other test framework as well.

## Services and Steps
Before reading through the documentation please take a look at the [Services]({{ site.baseurl }}{% post_url docker/2015-05-25-services %}) and [Steps]({{ site.baseurl }}{% post_url docker/2015-05-25-steps %}) documentation page so you have a good understanding how services and steps on Codeship work.

## Dockerfile
We will start by creating Dockerfiles that lets you run your Python based test suite in Codeship.

Please take a look at our [Dockerfile Caching best practices]({{ site.baseurl }}{% post_url docker/tutorials/2015-09-07-caching %}) article first to make sure you build your Dockerfile in a way that only invalidates the Docker cache when necessary.

```
# Starting from Python 2.7 base image
FROM python:2.7

# Set the WORKDIR to /app so all following commands run in /app
WORKDIR /app

# Adding requirements files before installing requirements
COPY requirements.txt dev-requirements.txt ./

# Install requirements and dev requirements through pip. Those should include
# nostest, pytest or any other test framework you use
RUN pip install -r requirements.txt -r dev-requirements.txt

# Adding the whole repository to the container
COPY . ./
```

This Dockerfile will give you a good starting point to install any further packages or tools you might need. Take a look at our [browser testing documentation]({{ site.baseurl }}{% post_url docker/2015-09-07-browser-testing %}) to find and install any further tools you might need for your build.

## codeship-services.yml

The following example will use the Dockerfile we created to set up a container we call project_name (please change to your specific project name) that will run your build. We're adding a [PostgreSQL container](https://hub.docker.com/_/postgres/) and [Redis container](https://hub.docker.com/_/redis/) so the tests have access to those two services.

When accessing other containers please be aware that those services do not run on localhost, but on a different hostname, e.g. "postgres" or "mysql". If you reference localhost in any of your configuration files you have to change that to point to the hostname of the service you want to access. Setting them through environment variables and using those inside of your configuration files is the cleanest approach to setting up your build environment.

```yaml
project_name:
  build:
    image: organisation_name/project_name
    dockerfile_path: Dockerfile
  # Linking Redis and Postgres into the container
  links:
    - redis
    - postgres
  # Set environment variables to connect to the service you need for your build.
  # Those environment variables can overwrite settings from your configuration
  # files if configured. Make sure that your environment variables and
  # configuration files work work together as expected.
  environment:
    - DATABASE_URL=postgres://postgres@postgres/YOUR_DATABASE_NAME
    - REDIS_URL=redis://redis
# Service definition that specify a version of the service through container tags
redis:
  image: redis:2.8
postgres:
  image: postgres:9.4
```

For more information about other services you can use with Codeship check out our [services and databases documentation]({{ site.baseurl }}{% post_url docker/2015-09-03-services-and-databases %}).

## codeship-steps.yml

Now we're going to set up our `codeship-steps.yml` file. Every step in a build gets its own clean container and linked services. Any setup commands that are necessary to setup a linked container (e.g. database migrations) need to be run for every step. While this duplicates some of the work, it also makes sure your parallelized test commands run completely independently.

```yaml
- name: ci
  type: parallel
  steps:
  - service: project_name
    command: nosetets tests/unit
  - service: project_name
    command: nosetests tests/acceptance
```

The same setup can be used with py.test.
<commit_msg>Update 2015-09-09-python.md<commit_after>---
title: Python on Docker
weight: 48
tags:
  - python
  - languages
  - docker
categories:
  - docker-integration
---
In this article you will learn about setting up a Python based project on our Docker infrastructure. We will use [nosetest](https://nose.readthedocs.org/en/latest/) and [py.test](http://pytest.org/latest/) for setting up the build, but the same works for any other test framework as well.

## Services and Steps
Before reading through the documentation please take a look at the [Services]({{ site.baseurl }}{% post_url docker/2015-05-25-services %}) and [Steps]({{ site.baseurl }}{% post_url docker/2015-05-25-steps %}) documentation page so you have a good understanding how services and steps on Codeship work.

## Dockerfile
We will start by creating Dockerfiles that lets you run your Python based test suite in Codeship.

Please take a look at our [Dockerfile Caching best practices]({{ site.baseurl }}{% post_url docker/tutorials/2015-09-07-caching %}) article first to make sure you build your Dockerfile in a way that only invalidates the Docker cache when necessary.

```
# Starting from Python 2.7 base image
FROM python:2.7

# Set the WORKDIR to /app so all following commands run in /app
WORKDIR /app

# Adding requirements files before installing requirements
COPY requirements.txt dev-requirements.txt ./

# Install requirements and dev requirements through pip. Those should include
# nostest, pytest or any other test framework you use
RUN pip install -r requirements.txt -r dev-requirements.txt

# Adding the whole repository to the container
COPY . ./
```

This Dockerfile will give you a good starting point to install any further packages or tools you might need. Take a look at our [browser testing documentation]({{ site.baseurl }}{% post_url docker/2015-09-07-browser-testing %}) to find and install any further tools you might need for your build.

## codeship-services.yml

The following example will use the Dockerfile we created to set up a container we call project_name (please change to your specific project name) that will run your build. We're adding a [PostgreSQL container](https://hub.docker.com/_/postgres/) and [Redis container](https://hub.docker.com/_/redis/) so the tests have access to those two services.

When accessing other containers please be aware that those services do not run on localhost, but on a different hostname, e.g. "postgres" or "mysql". If you reference localhost in any of your configuration files you have to change that to point to the hostname of the service you want to access. Setting them through environment variables and using those inside of your configuration files is the cleanest approach to setting up your build environment.

```yaml
project_name:
  build:
    image: organisation_name/project_name
    dockerfile_path: Dockerfile
  # Linking Redis and Postgres into the container
  links:
    - redis
    - postgres
  # Set environment variables to connect to the service you need for your build.
  # Those environment variables can overwrite settings from your configuration
  # files if configured. Make sure that your environment variables and
  # configuration files work work together as expected.
  environment:
    - DATABASE_URL=postgres://postgres@postgres/YOUR_DATABASE_NAME
    - REDIS_URL=redis://redis
# Service definition that specify a version of the service through container tags
redis:
  image: redis:2.8
postgres:
  image: postgres:9.4
```

For more information about other services you can use with Codeship check out our [services and databases documentation]({{ site.baseurl }}{% post_url docker/2015-09-03-services-and-databases %}).

## codeship-steps.yml

Now we're going to set up our `codeship-steps.yml` file. Every step in a build gets its own clean container and linked services. Any setup commands that are necessary to setup a linked container (e.g. database migrations) need to be run for every step. While this duplicates some of the work, it also makes sure your parallelized test commands run completely independently.

```yaml
- name: ci
  type: parallel
  steps:
  - service: project_name
    command: nosetests tests/unit
  - service: project_name
    command: nosetests tests/acceptance
```

The same setup can be used with py.test.

{'fraction_non_alphanumeric': 0.07060736267564743, 'fraction_numerical': 0.01254209731738474, 'mean_word_length': 4.232077764277035, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 6, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5206830', 'n_tokens_mistral': 2384, 'n_tokens_neox': 2213, 'n_words': 1109}