Build a sandbox to test changes before making them live

Regardless of if you’re a moderator or an admin, you will no doubt at some time think about making some change to your live site and wonder if this will bring shame on you, and/or cause yourself an enormous amount of work to put right again.

There is an easy solution to this: build yourself a sandbox! You can restore a backup of your live site to the sandbox and this will give you a representative post and user base, then you can play Dangerous Dan all you want.

(If it isn’t your site, then talk to the admin/site owner first, and make sure they are ok with you cloning the site.)

All you need is:

  • A host, preferably with the same OS as your live install.
  • A mail provider (at least temporarily for the setup)
  • The 30 minute install instructions
  • A backup of your live site.

HOST
I used a free tier AWS instance, and installed Ubuntu 16.04. I increased the size of the disk as it was too small to handle restoring the 4.5GB backup. I didn’t bother setting up a domain or encryption, or https. Just a straight box that I could reach via putty and a browser.

MAIL PROVIDER
I used AWS for this as well, I only wanted mail to complete the discourse setup and verify that the setup actually worked. The last thing I wanted was my sandbox to start sending emails out to our users. You could probably skip setting up email entirely.

DISCOURSE INSTALL
SSH into the box
sudo -s
apt-get install htop
dpkg-reconfigure -plow unattended-upgrades
apt-get update
apt-get upgrade
apt-get autoclean
apt-get autoremove
shutdown -r

When the box comes back up check if the login message says “a restart is required” (keep an eye out for this whenever you SSH into the box)

Follow the excellent Simple 30 minute basic install

POST INSTALL
Once the box is up and you’ve complete the web part of the setup, received your email, used that to login to the website, run a backup.
SSH into the box
Make a copy of your app.yml

sudo -s
cd /var/discourse/containers
cp app.yml LIVEapp.yml
nano app.yml

add “NOT-” to the beginning of the SMTP variables (to make sure that your sandbox won’t be able to send emails unless you change those settings again):

DISCOURSE_SMTP_ADDRESS: NOT-email...
DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: NOT-...
DISCOURSE_SMTP_PASSWORD: NOT-...

save the file and exit nano (Ctrl-o, enter, Ctrl-x)

Rebuild the app:

cd /var/discourse
git pull
./launcher rebuild app

When the rebuild is finished check that you can still reach the website and login etc.

Back in the CLI:

  • check how much disk space you have (and note it down somewhere)
    df -h
  • check how your RAM usage is (and note it down somewhere)
    free -h
  • Have a gander at htop to see what an unloaded blank install looks like
    htop
  • f10 or Ctrl-c to exit htop
    ./launcher cleanup

In the GUI go to sitename/admin/site_settings/category/backups and set a checkmark on “allow restore”

Visit your live site and download a recent backup (including uploads) from /admin/backups.

Go to /admin/backups and upload the backup.
Back in the CLI check how much space you have with free-h, IIRC the restore needs about 3x the size of the backup to complete without crashing because your disk is full. If in doubt, fix that now.
Restore the backup to your sandbox site.
While the restore is running, watch what is going on with htop and df-h (it’s a geek thing).
When the restore is complete, goto /admin/settings and change the following:
“disable emails” set a check mark.
Look through all of the settings (use “Only show overridden”) and change any site settings related to S3, CDNs, CSS, permalinks etc so you won’t be interfering (or masquerading) as your live site.
Back in the CLI:
./launcher rebuild app

You don’t really need to do it, but as you may have noticed, I’m a belt and braces kind of a guy, so…
shutdown -r

When it comes back up you should have a functioning site with content, but you won’t be able to login with your live credentials.

SSH into the sandbox

sudo -s
cd /var/discourse
./launcher enter app
rake admin:create

Answer the questions. You can either set a password for your live account, or create a new admin (I used none@nonexistent.com as an email).

Now you can login to the sandbox GUI with the email and password you just set.

The last thing to do is add the plugins which your live site has to your app.yml, then ./launcher rebuild app one last time, then configure any plugin settings as your live site has.

You now have a working sandbox to play with, including content, And damned be him that first cries, “Hold, enough!”.

20개의 좋아요

Quick question on this as pretty new to AWS

  • when setting the domain what did you use (if you dont have a domain) - I was able to use the public dns / IP to start but once you stop the server the IP address changes unless you use elastic IPs.
    I am now able to access it on the new IP - however will this not cause me issues with the IP changing constantly everytime I stop / start it when I need it.?

I used elastic IP for SSH, and the public dns for the web interface.

1개의 좋아요

Gonna go through this in the morning, thanks for putting this together

Take notes for the AWS setup (if you’re using them). I spent about 2 hours peering at the AWS docs and googling until I’d managed to get a machine that I could SSH into. I didn’t take any notes, as with each step I kept thinking “ok, so as soon as I figure out this minor thing I’ll be able to move on to the discourse install”.

The AWS doc’s aren’t exactly Ikea assembly instructions, I took a while to twig their terminology. Mind you, it could be worse.

1개의 좋아요

Agreed! To me, AWS is a twisty maze of passages that all look the same. Digital Ocean has much, much, less flexibility than AWS, but there’s relatively little that can go wrong setting up a droplet.

1개의 좋아요

Yes, I found AWS to be very… atomic. The bits are all there, but it takes some energy to create a molecule.

I first tried a Ubuntu VM on a Windows PC then my Synology. The windows PC died and my Syno was woefully weak on RAM… then I noticed Amazon’s free tier. Our live site is on AWS, so it was a match for me.

10$/month for a DO droplet isn’t much, but it is still 10$/month, and AWS’s complication kind of forced me to dig a bit deeper into what is going on behind.

1개의 좋아요
  • autoclean & autoremove after the upgrades
  • I have always kept my plugins in place during transfers from a server to another. One less rebuild.
  • Arubacloud’s 1€ VPS should fit the bill here, if 20GB SSD is sufficient. ScaleWay’s 2.99€/50GB is the next option.

That’s why I tried it too. Somehow I managed to create something that kept billing me even though all of my instances were shut down. I think it was an elastic IP, or maybe some kind of disk space.

Snapshots or volumes…

2개의 좋아요

Do you use https on your main site? Because by not setting it up here for testing, and then uploading your entire backup unencrypted over http you exposed it to anyone in the way listening, including emails, password hashes, private messages etc.

What you should have done is created a self signed cert, used letsencrypt, or simply went over an ssh tunnel. All these would protect you.

You should probably edit your post so others don’t make the same mistake.

Could you give us a walk through how to do that, particularly the creation of a self signed cert?

AWS free tier isn’t really suitable for Discourse - there’s not enough RAM, and adding swap files will go very badly as soon as they start to get used due to the I/O restrictions on EBS.

It might be alright for a sandbox, but if you run anything memory intensive (like a migration or upgrade) then it might grind to a halt.

“For a sandbox” being the main point here. The free tier instance does indeed limit what you can expect the box to do in a reasonable time (I can say for a fact that a rebake on 1.8 million posts just isn’t going to work). But for someone trying to evaluate plugins, or CSS or such, a free sandbox is a good thing to have.

1개의 좋아요

Agreed - if all you’re doing is messing with CSS then it’ll probably be fine, but if you’re installing plugins or updating using docker-manager there could be problems.

The issues we had didn’t just make things slow, they completely brought the OS to a standstill and we had to restart the server.

As you say - if it is just a sandbox then that’s not the end of the world, but worth being aware of.

매우 혼란스러운 점이 하나 있습니다. 서로 다른 도메인 이름 2개를 사용해야 하는 건가요?
하나는 이미 라이브 웹사이트가 실행 중인 도메인이고, 다른 하나는 이 '샌드박스 디스코 사이트’를 설치할 도메인인가요? (제 이해가 맞다면, 디스코 인스턴스는 IP 주소로는 설치, 실행, 사용이 불가능합니다.)

그리고 라이브 사이트에서 이미 S3 백업을 사용하고 있다면, 이 샌드박스 디스코 인스턴스에 백업을 사용/복원하기 위해 먼저 로컬 PC로 백업을 다운로드해야 하나요?

1개의 좋아요

네, 각 사이트에는 고유한 FQDN이 필요합니다.

스테이징 사이트를 설정하여 동일한 백업 버킷을 사용하도록 한 후, 프로덕션 사이트의 백업에서 직접 복원할 수 있습니다.

4개의 좋아요

고맙습니다.

하지만 스테이징 사이트의 버킷을 별도로/새롭게 유지하는 것이 더 좋을 것 같습니다. 실수로 프로덕션의 최신(그리고 아마도 유일한) 백업을 덮어쓰는 일이 생기지 않도록 해야 하니까요!

1개의 좋아요

저는 스테이징 사이트에서 자동 백업을 꺼놓습니다. yml 파일의 환경 변수로 설정할 수 있으므로 변경할 수 없습니다.

파일을 옮기는 단계를 거치지 않고 다른 서버로 백업을 복원할 수 있는 기능은 매우 유용합니다.

5개의 좋아요

이 사이트에서 이렇게 오랫동안 많은 사람들을 도울 수 있을 정도로 시간이 많다고 믿기 어렵습니다.

어떻게 생계를 유지하고, 자신의 삶과 가족에 충실하면서, 다른 사람들에게 이렇게 효율적으로 도움을 줄 수 있는 걸까요!!

저에게는 너무 힘들어 보입니다.
제 친구들에게 말해도 마찬가지입니다.

메타(구 페이스북)나 다른 포럼에서 서로를 돕는 사람들을 많이 봤습니다.
하지만 이렇게 많은 세월 동안 모든 사람에게 도움을 주는 것은 쉽지 않아 보입니다.
당신에게는 뭔가 특별한 것이 있는 것 같습니다.

P.S.: 아니면 제가 인생에서 중요한 무언가를 놓치고 있는 걸까요.

5개의 좋아요