5
votes

I'm new to AWS CodeDeploy, in fact, I'm just experimenting.

I'm trying to handle continuous integration using CircleCI 2.0 and AWS CodeDeploy so that when I push changes to my django project to development in github, it builds in CircleCI and then pushes the deploy to an S3 and after that the changes are deployed to the EC2.

I did all the configurations in CodeDeploy, and I copied the appspec from a guy in github that used CodeDeploy with a Django/DRF project (such as mine). The only difference is that he was using another kernel in his EC2 instance (I think AWS linux) and I'm using ubuntu. So I had to change the username in the runas section of every hooks part. The first time I ran the create-deployment command in the aws cli the deployment failed with this message:

LifecycleEvent - ApplicationStop
Script - scripts/stop_application.sh
[stderr]No passwd entry for user 'ec2-user'

As it turned out, I forgot to change the runas useer in the ApplicationStop hook. Then I changed it, did the push and the create-deployment again, but the error remains to be the same. Do I need to do something else for the changes in the appspec to be considered or why is this happening?

Here is the appspec.yml file:

version: 0.0
os: linux
files:
  - source: /
    destination: /home/ubuntu/taptop_web
permissions:
  - object: /home/ubuntu
    pattern: "**"
    owner: ubuntu
    group: ubuntu
hooks:
  BeforeInstall:
    - location: scripts/clean_instance.sh
      timeout: 6000
      runas: root
  AfterInstall:
    - location: scripts/install_os_dependencies.sh
      timeout: 6000
      runas: root
    - location: scripts/install_python_dependencies.sh
      timeout: 6000
      runas: ubuntu
    - location: scripts/migrate.sh
      timeout: 6000
      runas: ubuntu
  ApplicationStart:
    - location: scripts/start_application.sh
      timeout: 6000
      runas: ubuntu
  ApplicationStop:
    - location: scripts/stop_application.sh
      timeout: 6000
      runas: ubuntu

And the stop_application.sh

#!/usr/bin/env bash
cd /home/ubuntu/taptop_web
ps auxw | grep runserver | awk '{print $2}' | xargs kill
1

1 Answers

6
votes

The only thing you need to do to fix your issue is have a successful deployment. It only appears as though it didn't update because when you do the deployment, it will run ApplicationStop from the previous revision. This is often confusing, but it works that way because only a revision should know how to stop its own application - if the stop commands changed between revisions, the new stop command wouldn't work.

That being said, it's not an uncommon issue where customers have a ApplicationStop script that fails due to an issue in the script, so a deployment will keep failing without intervention. If there's your issue, follow this guide to get out of the situation.