A Tale of Two Deployments
It was the best of times, it was the worst of times, it was the age of remote work, it was the age of pyjamas, it was the epoch of bread baking, it was the epoch of pineapple pizza, it was the season of Light, it was the season of Darkness…
This is a short but exciting story about two system updates. Spoiler alert: no one has been guillotined.
How to use Ansible to update your Django web app
Now, as you have overcome or evaded the reefs, shoals and swirls of initial development and deployment and your appetite
grows, you ask “How do I automate the update and restart of my web app when I change the code?” There is already
one simple and elegant method on our blog, that uses one of the possible
push to publish methods, but this time we will dip our toes into vast waters of Ansible automation.
Introduction to scheduled tasks helper scripts
For all PythonAnywhere users who like to automate their workflow using scripts there’s already the pythonanywhere package which provides an interface for some PythonAnywhere API features.
If you’re one of them, you might be interested in some recent additions for programmatic management of Scheduled Tasks.
Outage report 7 July 2020
We had an unplanned outage the day before yesterday; it was our first big one since July 2017. It was caused by an extremely unlikely storage system failure, but despite that it should not have led to such a lengthy downtime, and should not have affected so many people. We have some plans on what our next steps should be, and will be implementing at least some of them over the coming months.
At 16:06 UTC on 7 July 2020, a storage volume failure on one of our storage servers caused a number of outages, starting with our own site and also with our users’ programs (including websites) that were dependent on that volume, and later spreading to other hosted sites. Because all of the data that we store on behalf of our users is backed up and mirrored, no data was lost or at risk, but the outage was significantly longer than we would like.
The effects were:
- Our own site was unavailable or generating an excessive number of errors from 16:06 to 18:53 UTC.
- For accounts that were stored on the affected file storage:
- Websites were unavailable in general from 16:06 to 19:46 UTC, with some taking until 21:24 UTC to be fully available.
- Scheduled tasks did not run between 16:06 and 18:53-19:46 UTC (the precise end time depending on the account)
- Always-on tasks did not run between 16:06 and 18:53-19:46 UTC (the precise end time depending on the account)
- For accounts that were not using the affected file storage
- Scheduled tasks, and always-on tasks were unaffected apart from a short window of about five minutes between 18:53 and 19:46 UTC.
- Websites were also unaffected apart from that window if they were already up and running when the problems started at 16:06 UTC. However, they could not be started up or reloaded between 16:06 and 18:53, and would have had a brief outage sometime between 18:53 and 19:46 UTC.
- However, of course, the problems on our own site would also have affected the owners of these accounts if they needed to log in to run or change things.
This post gives a more detailed timeline of what happened, and describes what steps we are taking to prevent a recurrence.
COVID-19 update: PythonAnywhere is now all-remote
Scary times. We hope everyone reading this is well and keeping safe!
We thought it would be a good idea to tell you how we’re managing the current
crisis at PythonAnywhere. We switched over to remote working last Thursday, 12 March;
there are obviously private and public health reasons why that was a good idea,
but there’s a reason specific to us, which we thought would be worth sharing.
How to use shared in-browser consoles to cooperate while working remotely.
One of the challenges of remote work is when you need to work together on one thing.
Our in-browser consoles are one of the core features of our service. Almost since the beginning, PythonAnywhere
has been able to share consoles – you entered the name of another user or an email
address, and they got an email telling them how to log in and view your Python
(or Bash, or IPython) console. If you use an email, the person you invite doesn’t have to be PythonAnywhere registered user.
System updates on 3 and 5 March
On 3 March we upgraded our EU-based system at
eu.pythonanywhere.com to the latest version of our code, and this morning (5 March) we upgraded our US-based system at
www.pythonanywhere.com to the same version.
Everything went very smoothly, and all systems are working well. There were a bunch of infrastructure-related changes in this update:
- We’ve made some improvements to the beta of our new virtualisation system, which is currently in public beta. More about that next week, we hope!
- We’ve updated almost all of our machines to the most recent AWS Intel server types; the remainder will be upgraded over the coming two weeks. CPU geeks will be glad to hear that we’re going to start experimenting with AMD. We might also consider ARM for our own internal systems, though right now it feels like sticking with x86-64 for the servers where our users run their code is the best option (let us know if in the comments if you disagree!)
- A certain amount of code that was (somewhat embarrassingly) still Python 2 was upgraded to Python 3. blush
As usual, there were also a number of minor tweaks and minor bugfixes.
Onwards and upwards!
The PythonAnywhere newsletter, January 2020
So, we have managed to break another record for our longest period ever between two monthly newsletters. It has been sixteen busy months between September 2018 and now, so we have made 2019 an official Year Without a Newsletter.
Happy New Year, and a warm welcome to the January 2020 PythonAnywhere newsletter. Hooray!
Here is what has happened since our last one.
Python 3.8 now available!
If you signed up since 26 November, you’ll have Python 3.8 available on your account – you can use it just like any other Python version.
If you signed up before then, it’s a little more complicated, because adding Python 3.8 to your account requires changing your system image.
System update on 21 November 2019
This morning’s system update went smoothly; some websites did take a bit longer than we expected to start up afterwards, but all is well now.
There are two big new features that we have introduced which are going through some final post-deploy tests before they go live – a new system image (called
fishnchips) to support Python 3.8 and to add on a number of extra OS packages that people have been asking us for, and an update to our virtualization system that will fix a number of problems with specific programs. We’ll be posting more about those when they’re ready to go live. [Update: we’ve posted about the fishnchips system image here.]
But there were a number of other things we added:
- We’ve added the ability to restart an always-on task without stopping it, waiting for it to stop, and then starting it again – there’s a new “restart” button on the far right of the tasks table.
- You can now temporarily disable a website without deleting it – the button is near the bottom of the “Web” page.
- And, of course, the normal set of minor tweaks, bugfixes, and the like.