求助：如何通过Dokku正确部署Bitbucket上的Laravel项目

Got it, let's sort this out properly. Shoving migrate or seed commands directly into your Dockerfile is definitely not the right move—those are runtime tasks that should happen after your app is deployed, not during the build. Plus, you probably don’t want seeds running every single time you deploy (hello duplicate test data!). Let’s walk through the correct workflow for your Dokku + Laravel + Bitbucket setup:

1. First, Clean Up Your Dockerfile #

Start by removing any php artisan migrate or seed commands from the end of your Dockerfile. Build stages are for assembling your app’s image—they shouldn’t interact with production services like your database (which might not even be reachable during the build process).

2. Use Dokku Post-Deploy Hooks for Runtime Tasks #

Dokku lets you run scripts automatically after a successful deploy, which is perfect for Laravel’s migration and seeding needs. Here are two reliable options:

Option A: Server-Side Post-Deploy Hook #

This keeps the deploy logic on your Dokku server, giving you full control without modifying your repo:

• SSH into your Dokku server and create a hook directory for your app:

  mkdir -p /home/dokku/your-app-name/hooks/post-deploy
  

• Create an executable script in that directory (replace your-app-name with your actual app name):

  nano /home/dokku/your-app-name/hooks/post-deploy/01-laravel-tasks
  

• Paste this content into the script (adjust as needed—comment out the seed line if you don’t want it running on every deploy):

  #!/bin/bash
  set -e
  
  # Run database migrations (--force skips the production environment prompt)
  dokku run your-app-name php artisan migrate --force
  
  # Optional: Run seeders (only uncomment if you explicitly want this on every deploy)
  # dokku run your-app-name php artisan db:seed --force
  

• Make the script executable and set the correct ownership:

  chmod +x /home/dokku/your-app-name/hooks/post-deploy/01-laravel-tasks
  chown dokku:dokku /home/dokku/your-app-name/hooks/post-deploy/01-laravel-tasks
  

Now, every time you deploy your app, this script will run automatically after the container is up.

Option B: Repo-Based Deployment Script #

If you prefer to keep deploy logic in your project repo, create a deploy.sh file at your project root:

#!/bin/bash
set -e

# Run migrations with force flag for production
php artisan migrate --force

# Optional: Conditional seeding (use an env var to trigger only when needed)
# if [ "$RUN_SEEDS" = "true" ]; then
#   php artisan db:seed --force
# fi

• Make it executable locally before pushing to Bitbucket:

  chmod +x deploy.sh
  

• On your Dokku server, set this script to run post-deploy:

  dokku config:set your-app-name DOKKU_DEPLOY_TASKS="./deploy.sh"
  

Or, if you want manual control, run it after deploy with:

dokku run your-app-name ./deploy.sh

3. Verify Bitbucket Integration #

Make sure your Dokku app is properly linked to Bitbucket to pull code:

• On your Dokku server, add the Bitbucket remote to your app:

  dokku git:remote add your-app-name git@bitbucket.org:your-username/your-repo.git
  

• Alternatively, set up a Bitbucket webhook to trigger deploys automatically:
  1. Go to your Bitbucket repo > Settings > Webhooks > Add webhook
  2. Set the URL to http://your-dokku-server-ip/your-app-name/deploy (use HTTPS if you have SSL configured)
  3. Trigger the webhook on "Repository push" events
  4. Add your Dokku app’s SSH key to Bitbucket (run dokku ssh-keys:list your-app-name to get the key)

4. Critical Laravel Environment Setup #

Don’t forget to set your Laravel environment variables in Dokku—this ensures your app can connect to the database and run migrations:

dokku config:set your-app-name APP_ENV=production APP_KEY=$(dokku run your-app-name php artisan key:generate --show) DB_HOST=your-db-host DB_DATABASE=your-db-name DB_USERNAME=your-db-user DB_PASSWORD=your-db-pass

Why Your Original Dockerfile Approach Was Flawed #

• Build-time vs Runtime: Docker builds are stateless and don’t have access to production services like your database—migrations might fail if the DB isn’t reachable during the build.
• Unintended Side Effects: Running seeds on every build/deploy can duplicate test data in production, which is almost never what you want.
• Lack of Control: Dockerfile commands run once during the build—if you fix a migration later, it won’t run unless you rebuild the entire image, which isn’t ideal.

内容的提问来源于stack exchange，提问作者Ernestyno