https://dchua.com/tags/deployments/ Recent content in deployments on davidchua Hugo -- gohugo.io en-us Sun, 22 Jan 2017 00:00:00 +0000 https://dchua.com/posts/2017-01-22-using-multiple-buildpacks-in-deis/ Sun, 22 Jan 2017 00:00:00 +0000 https://dchua.com/posts/2017-01-22-using-multiple-buildpacks-in-deis/ To use multiple buildpacks with your Application Deployment on Deis Workflow, is pretty straight forward. As heroku-buildpack-multi is already built into deis' slugbuilder, all you need to do is to create a .buildpacks file in your repository, insert your required buildpacks, commit and push away. An example .buildpack could look like: # .buildpacks https://github.com/cloudfoundry/heroku-buildpack-ruby.git https://github.com/gaumire/heroku-buildpack-mysql Enjoy. References Github - multi-buildpacks https://dchua.com/posts/2017-01-16-fixing-omniauth-redirecting-to-a-uri-with-port/ Mon, 16 Jan 2017 00:00:00 +0000 https://dchua.com/posts/2017-01-16-fixing-omniauth-redirecting-to-a-uri-with-port/ Came across this problem the other day when deploying a Rails application that is sitting behind Kubernetes and Deis With my Rails application using OmniAuth and its Facebook strategy, after a user logins, hits Facebook and returns a redirection, the URL returned has its port 80 embedded in the return URI like: https://domain.com:80. In most cases, this wouldn’t be a problem but Facebook would return an error as the return URI (with the port 80) is not whitelisted hence creating a bad flow for your user. https://dchua.com/posts/2014-08-28-mysql-backup-process/ Thu, 28 Aug 2014 00:00:00 +0000 https://dchua.com/posts/2014-08-28-mysql-backup-process/ How I usually prepare the backup regime of my mysql/mariadb databases of all my newly provisioned servers is to do the following tasks: Create a DBA user > create user 'dba'@'localhost'; Give the DBA user only the relevant access just for backing > GRANT SELECT, SHOW VIEW, RELOAD, REPLICATION CLIENT, EVENT, TRIGGER ON *.* TO 'dba'@'localhost'; > GRANT LOCK TABLES ON *.* TO 'dba'@'localhost'; > FLUSH PRIVILEGES; Setup a backup script! https://dchua.com/posts/2013-08-29-properly-using-ssh-agent-forwarding-in-capistrano/ Thu, 29 Aug 2013 00:00:00 +0000 https://dchua.com/posts/2013-08-29-properly-using-ssh-agent-forwarding-in-capistrano/ You’ve probably seen this in your capistrano deploy script. # /config/deploy.rb set :ssh_options, { :forward_agent => true } SSH Agent Forwarding is a great way to keep SSH keys manageable as it allows the deployment server to use your own local private key to authenticate to the git repository, instead of having to give your deployment server access to your git repository. Github has an awesome article explaining this. My tl;dr version: https://dchua.com/posts/2010-05-04-getting-integrity-up-and-running-w-email-notification-and-test-database-raking/ Tue, 04 May 2010 00:00:00 +0000 https://dchua.com/posts/2010-05-04-getting-integrity-up-and-running-w-email-notification-and-test-database-raking/ After spending a couple of hours trying to get integrity setup, I thought I’ll share and document my process for future reference. So what is Integrity? From their website: “As soon as you push your commits, Integrity builds your code, run your tests and makes sure everything works fine. It then reports the build status using various notifiers back to you and your team so everyone is on the same page and problems can be fixed right away.