Because AWS decided to disable access to all of the Cloud9 workspaces by the end of this month on June 30, 2019, I have no choice but to migrate them to AWS Cloud9. Here’s the story.
Backup your whole database on SQL dump and leave it on your old Cloud9 workspace. This is very important after you’re migrated AWS Cloud9.
With this, after the migration, that SQL dump file will be on your AWS Cloud9 as well. This can be helpful if you had a large database.
Because, as far as I know, there is no way to do SSH to old Cloud9 IDE. So, there’s no way to do SCP (secure copy) to copy the dump file into your migrated AWS Cloud9.
This because AWS Cloud9 won’t migrate the whole database for you. You need to do this later as additional migration tasks below.
Easy and quick
The migration process itself is easy and very quick. AWS provided the completed documentation. Along with that, they also provided very friendly and practical guidelines.
I begin from old Cloud9 and follow the steps from there. It’s really easy so I can get the new workspace on AWS Cloud9 up, after working on it for 15 minutes.
After you had migrated, don’t forget to perform the additional tasks. This additional task was to import data to your database on your new workspace on AWS Cloud9.
This is why I mentioned in the beginning that you need to export the database on your old C9 workspace first. Therefore, you’ll get that file on a new workspace and only need to perform the command to import the database from that file.
My problems begin from there. The new workspace I set up on AWS C9 was lack of storage. After importing the data into the database, the storage is run out so I look for the way to add additional storage.
I found that documentation and copy the resize.sh script. But, when I run it, there are some errors I need to fix. See below.
1. I need to set up the credential
The first error I encounter is:
Unable to locate credentials. You can configure credentials by running "aws configure".
So, I run that “aws configure” and I need to insert the following information properly.
- AWS Access Key ID
- AWS Secret Access Key
- Default region-name
- Default output format. I use the default one: “JSON”
Once I finished inserting all the information above, then I re-run the resize.sh script again. This time, I got such error:
An error occurred (UnauthorizedOperation) when calling the DescribeInstances operation: You are not authorized to perform this operation
2. Permission problem
After exploring that error, I found out it was a permission problem. I need to add attach the proper “policies” for the IAM users I used to sign in with AWS Cloud9.
Since I am not sure which one, I just attach the “Administrator” policy from the existing policies list.
I know this is not a best practice but I haven’t had a chance to explore more details to find out the proper permissions to run that resize.sh script.
In the end, after I have done with all of these, I remove that attached “Administrator” policy.
3. It points me to the wrong region
See the image on the left. When I clicked that “Manage EC2 Instance”, it brings me to the EC2 dashboard.
But there is no instance for that AWS Cloud9. The regions it opens is “us-west-2”
That was weird. I thought it’s one of the bugs so I continue to try running the resize.sh script again. This time, it gave me another error
An error occurred (InvalidInstanceID.NotFound) when calling the DescribeInstances operation: The instance ID 'i-xxxxxxxxxxxxx' does not exist
Ok. That makes sense since I can’t see the EC2 instance on the EC2 dashboard for the “us-west-2” region.
Then, I look for this instance on the other regions and find out the EC2 instance for this AWS C9 was on the “us-east-1” regions
I know, it’s weird but this happened.
The next thing is obvious. I re-run that “aws configure” command and replace the region information with “us-east-1”.
The last, I rerun that resize.sh script. This time, it runs smoothly without any more errors.
I don’t know if this was AWS Cloud9 bugs or not. It’s hard to believe a service like AWS allowed such bugs to exist.
Maybe I missed some steps when I follow the guidelines from old C9 to AWS C9.
If anyone does have a similar experience, then please let me know.
Otherwise, it must be me that I missed one step that caused all of those errors to happen.