The story of migrating Cloud9 to AWS Cloud9
Here’s the story of mine migrating Cloud9 to AWS Cloud9. 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.
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.
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
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.
So that’s my story migrating Cloud9 to AWS Cloud9. What about yours?
Cloud9 alternatives after it moved to AWS Cloud9
As we approach the end of the month, the closer we are to the day when we will say goodbye the workspace we love on Cloud9 (c9.io). They will disable our access to the workspace there and we only have one option: download and migrate it somewhere else. But what Cloud9 alternatives after it moved to AWS Cloud9?
The first Cloud9 alternatives: AWS Cloud9 I had migrated some of the workspaces belong to the client’s project last week.
Repl.it as one of Cloud9 IDE alternative
As the Cloud9.io will disable its service at this end of the month (June 30, 2019), I have no choice but to explore some alternative options to replace it. Here’s one of Cloud9 IDE alternative I found: Repl.it.
When I tweeted about this, two other Twitter accounts asked me to try their cloud IDE services. One of them is Repl.it.
Because I was busy at that time, I just add their site to a bookmark.
Gitpod as the alternative Cloud IDE
As of now, it’s still in public BETA (so no prices) – according to their official representative. Gitpod, which is said to extend GitHub, is an online integrated development environment (IDE). So basically, it’s a cloud IDE. Therefore, let’s find out: Is Gitpod good enough as the alternative Cloud IDE?
Gitpod promises to provide the user with a fully working development environment. What? Another cloud IDE? Gitpod says that it doesn’t aim at replacing desktop development because admit it, nothing beats the old school user interface.
My efforts to install Ruby 2.3.6 on Gitpod
Gitpod is the only IDE that’s integrating seamlessly with Github. However, by default, they only provide the latest Ruby 2.5 and 2.6. It is good to always provide Ruby’s latest version. It’s an ideal approach. Unfortunately, the web development project is not that ideal. One of my client’s project is still requiring Ruby 2.3.6 for various reasons I can’t describe here. So, how to install Ruby 2.3.6 on Gitpod IDE?
Free IDE for web developer – Codelobster IDE
What you need to know about Gitpod if you’re Github user
First, Gitpod and Github are different companies. But Gitpod service will make your Github experience more delightful. Here is what you need to know about Gitpod if you’re Github user like me.
The only cloud IDE which works seamlessly with Github It’s the only cloud IDE which works seamlessly with the Github repository. At least, that’s what I know when I write this post. If you need to run that git clone blah blah on the other IDE to clone the codes from Github repo, it’s not the case with Gitpod.
Valuable things that make Gitpod.io service interesting
As I’ve told you on the previous post, I began to explore its valuable features after I got the **Unlimited ** plan from Gitpod.io team. Here are the valuable things that make Gitpod.io service interesting, after I do my exploration.
Seamless Github integration This is the first feature I explore. I wonder how well it’s integrating to Github platform. I start with the registration process. After I click that Get started button on their pricing page, I get a Github sign-in page.
Got nice surprises from Gitpod team
Gitpod is the only cloud IDE that integrates seamlessly with Github. At least that’s what I know when I am writing this. Here’s how I got nice surprices from Gitpod team.
How I found Gitpod I found it almost a year ago. At that time, Amazon acquired Cloud9.io, the cloud IDE I used to work. I used its free plan since it’s already provided me with one private workspace. However, I predicted that some days, they’re going to change it.
The keys to giving IAM users access to AWS C9
This is my story when I need to give IAM users on the same AWS account, access to open and work on existing AWS Cloud9 workspace. It’s not straightforward to give access to AWS C9 for IAM users. Here are the keys to giving IAM users access to your AWS C9 – so they don’t need to login as root user.
The AWS docs did provide the detailed guides to do this.