No cruft, let’s just start.
Continue reading “A Shiny New Vuejs v3 Web App Using & Deployed to Amplify/AppSync/Cognito”Category: AWS
Troubleshooting Node.js Deploys on Beanstalk – The Express v4 node ./bin/www Switch Up
I’ve gotten a ton of 502 errors and related issues that crop up when deploying the Beanstalk. One of the issues that cropped up a few times recently, until I stumbled into a working solution was the 502 NGINX error. I went digging around and ended up just trying to deploy a default, fresh from the ‘express newAppNameHere’ creation and still got the error.
I went digging through the Beanstalk configuration for the app and found this little tidbit.
I’ve pointed out the section where I’ve added the command.
[sourcecode language=”bash”]
node ./bin/www
[/sourcecode]
Based on the commands that are executed normally, it seems `npm start` would work work to get the application started. But I have surmised the issue is that the commands are executed sequentially;
[sourcecode language=”bash”]
node server.js
node app.js
npm start
[/sourcecode]
When these are executed in order, errors crop up and the command that should work `npm start` begins with a corrupted and error laden beginning. Leaving the application not running. However by adding the `node ./bin/www` to the text box all the others are skipped and this command is issued, resulting in a running application.
The other thing is to follow the now standard approach of just issue `npm start`, but being sure to replace what I put in the text box above (`node ./bin/www`) with `npm start` so that beanstalk only runs npm start instead of the ordered execution.
Mapping Domain Names with name.com, Elastic Beanstalk, Elastic Load Balancer and AWS Route 53
I finally wrapped up my name server and DNS mapping needs with Name.com, Route 53 and Elastic Beanstalk. Since this was a little confusing I thought a short write up was in order. Thanks to Evan @evandbrown for helping out!
The first thing needed is a delegation set of name servers for your DNS and name server provider. These can be found by creating a hosted zone. The way to do this is open up the AWS Management Console and navigate into the Route 53 management area. The Route 53 icon is under the Compute & Networking section on the management console.
Upon navigating to the Route 53 console area click on the Create Hosted Zones button.
When the zone is created then the delegation set can be found under the Hosted Zone Details. This delegation set now needs setup as the name servers for whoever, in this case name.com, is the domain provider.
Open up the management console for the name server administration.
…
Upon adding them the list should look something like this.
Once the name servers are setup, those will need time to propagate. Likely this could take a good solid chunk of time, somewhere in the hours range likely, and don’t be surprised if it takes a little bit more than a day.
While the propagation starts navigate back to the AWS Management Console and open up the EC2 section of the console. On the right hand side of the Resources list there is a Load Balancers section. Click it.
In this section there is a listing of all load balancers that have been created manually or by Elastic Beanstalk.
Make note of the Load Balancer Name for selection in Route 53. This is what Route 53 needs in order to point an alias at for incoming traffic to that particular Elastic Beanstalk application. In this particular image above there are 4 load balancers listed, the easiest way to prevent confusion is to take note of the load balancer name at the time of creation, but this is the easiest way to find them otherwise.
Now when going back to the hosted zone to set it up with the appropriate information, create a new record with the appropriate name, in this case I was setting up the admin.deconstructed.io (no it isn’t live yet, I just set it up to test it out) to point to an alias target. Just leave the Type set to A – IPv4 address and click the radio control so that Alias is set to Yes. In the alias target select the appropriate load balancer for the Elastic Beanstalk (or whatever it points to) application.
That’s it, give it a few hours (or a day) and eventually the domain or subdomain will be pointed appropriately at the Elastic Beanstalk load balanced application.
Backup Riak – Learning About Distributed Databases :: Issue 001
I’ve got more than a few series in the queue, so why not another one eh! The intent is, I’ll grab a specific topic to break down and add details to related to distributed systems, primarily around Riak. I will however diverge into other distributed databases too, but I’ll primarily be sticking to Riak. Without more introduction, the first topic is…
Backing Up and Recovery of Riak (Nodes)
I’ve been asked approximately 423,983,321.7 zillion times how this is done. So here’s a quick summary and respective links to the best ways to backup Riak, how to recover nodes.
When backing up Riak there are two key things that need copied to the backup storage; the ring and data directories. Each of these things are specific based on the backend used with Riak. In addition to the core backup containing the ring and data, another good thing to backup is the configuration directory. When recovering this comes in useful.
For the locations of data, it depends slightly based on the operating system being used. The two big variances are OS-X and Linux Distros. On OS-X the data path, ring data and configuration are located at the locations listed below:
- Bitcask data: ./data/bitcask
- LevelDB data: ./data/leveldb
- Ring data: ./data/riak/ring
- Configuration: ./etc
For each specific distro, there are slight variations on where the locations are, for a full list check out the Basho Riak docs on backups. But on Linux distros the paths are as follows:
Debian and Ubuntu
- Bitcask data: /var/lib/riak/bitcask
- LevelDB data: /var/lib/riak/leveldb
- Ring data: /var/lib/riak/ring
- Configuration: /etc/riak
Fedora and RHEL
- Bitcask data: /var/lib/riak/bitcask
- LevelDB data: /var/lib/riak/leveldb
- Ring data: /var/lib/riak/ring
- Configuration: /etc/riak
Other Operating System Paths
Freebsd
- Bitcask data: /var/db/riak/bitcask
- LevelDB data: /var/db/riak/leveldb
- Ring data: /var/db/riak/ring
- Configuration: /usr/local/etc/riak
SmartOS
- Bitcask data: /var/db/riak/bitcask
- LevelDB data: /var/db/riak/leveldb
- Ring data: /var/db/riak/ring
- Configuration: /opt/local/etc/riak
Solaris
- Bitcask data: /opt/riak/data/bitcask
- LevelDB data: /opt/riak/data/leveldb
- Ring data: /opt/riak/ring
- Configuration: /opt/riak/etc
When backing things up, it’s important to note that each node could have slightly inconsistent data. The data however is rebuilt by the Riak read-repair system once it is recovered and brought into use.
Backup Jobs
One of the easiest ways to backup Riak is to setup a cron job with your choice of cp, rsync or tar. Then just get those files onto whatever your choice of backup medium. An example tar cron job to backup a Bitcask backend is shown below (snagged from the documentation) just to give you an idea of where to start.
[sourcecode language=”bash”]tar -czf /mnt/riak_backups/riak_data_`date +%Y%m%d_%H%M`.tar.gz /var/lib/riak/bitcask /var/lib/riak/ring /etc/riak
[/sourcecode]
For a leveldb back end the most important thing to note is that the node must be stopped. The basic workflow of backing up a node in this manner is to stop the node, backup the data, ring and configuration and then start the node back up.
Backup Recovery / Restoring
When recovering data on a node that is replacing an existing node that has the same name (fully qualified or IP) then follow the steps below:
- Install Riak
- Restore the old node’s configuration, data & ring.
- Start the node
Once you’ve got the node started back up it’s a good idea to do a ping or status against the node to verify it is in a good state.
If node names have been changed there are additional steps.
- Mark the original instance down[sourcecode language=”bash”]riak-admin down [/sourcecode]
- Join the restored cluster [sourcecode language=”bash”]riak-admin join [/sourcecode]
- Replace the original with [sourcecode language=”bash”]riak-admin cluster force-replcae [/sourcecode]
- Get the cluster plan built [sourcecode language=”bash”]riak-admin cluster plan[/sourcecode]
- Commit the changes [sourcecode language=”bash”]riak-admin cluster commit[/sourcecode]
- Change the -name setting in the vm.args configuration file to match the new name.
- Change & verify that the IP reflects the instances IP in the app.config for http and protocol buffer interfaces.
Cluster Backups via Riak Enterprise Multi-Data Center (MDC)
In the above sections I wrote about the traditional backup approaches. This is very similar to the way RDBMS are backed up. However, with a distributed system like Riak there is another great alternative if you’re utilizing multiple datacenters and Enterprise Riak. In this version of Riak, which is basically Riak with additional features and capabilities, one of the possible backup scenarios is to use the Multi-Data Center, or MDC, to replicate a duplicate cluster and use it as an active, real-time and always ready backup.
One workflow that is an exceptionally effective way to provide backups is to setup the “backup” cluster beside the current operative cluster. As an example, if your cluster is operational in AWS and it is running in X region and Y zone then you’d want to put the backup cluster in that same region and zone. Once you’ve setup Riak Enterprise and MDC, then just setup a full sync. Once the full sync is done you can then remove the backup cluster and it provides a point in time backup of the data.
[sourcecode language=”bash”]riak-repl start-fullsync[/sourcecode]
It’s easy to schedule full sync operations to low usage periods and it is also possible to pause and resume full sync operations.
[sourcecode language=”bash”]riak-repl resume-fullsync<br />riak-repl pause-fullsync[/sourcecode]
The variations on backing up data with Riak Enterprise and MDC are pretty expansive. Doing a point in time, maintaining a secondary live copy of the data, using the replication as a data dump to another cluster or even just using the MDC replication to dump all of the data to a single instance.
File System Snapshots
One other technique that is extremely efficient, fast and thorough is snapshotting the file system. The backup workflow for snapshots is extremely easy. First stop Riak, then snapshot, then start Riak again. Of all the methods, snapshotting is one of the easiest of the options. Just like setting up a cron job, automating snapshots based on some pre-defined schedule and meshing that with automated start and stop of Riak provides a very thorough backup.
With these options, have fun strategizing your stratagems into strategies for backups.
Diskettes
One of the oldest, tried and true backups is the old diskette. The bestest way to backup with diskettes is to backup each node on three diskettes each. The send one of each diskettes to a geographically dispersed to a bank lock box or other secure facility. Do this for each node, and if need be use as many diskettes for each node as needed. A particularly useful method is to use the sharded zip strategy to stripe a backup across many diskettes. Once each lock box has a copy of the node for each node in the cluster, you’ll have one of the most secure backups in existence. Nothing compares to the diskette backup!
References:
Red Hat, OpenShift PaaS and Cartridges for Riak
Today I participated in the OpenShift Community Day here in Portland at the Doubletree Hotel. One of the things I wanted to research was the possibility of putting together a OpenShift Origin Cartridge for Riak. As with most PaaS Systems this isn’t the most straight forward process. The reason is simple, OpenShift and CloudFoundry have a deployment model based around certain conventions that don’t fit with the multi-node deployment of a distributed database. But there are ways around this and my intent was to create or come up with a plan for a Cartridge to commit these work-arounds.
After reading the “New OpenShift Cartridge Format – Part 1” by Mike McGrath @Michael_Mcgrath I set out to get a Red Hat Enterprise Linux image up and running. The quickest route to that was to spool up an AWS EC2 instance. 30 seconds later I had exactly that up and running. The next goal was to get Riak installed and running on this instance. I wasn’t going to actually build a cluster right off, but I wanted at least a single running Riak node to use for trying this out.
In the article “New OpenShift Cartridge Format – Part 1” Mike skips the specifics of the cartridge and focuses on getting a service up and running that will be turned into a Cartridge. As Mike writes,
What do we really need to do to create an new cartridge? Step one is to pick something to create a cartridge for.
…to which my answer is, “alright, creating a Cartridge for Riak!” 😉
However, even though I have the RHEL instance up and running already, with Riak installed, I decided I’d follow along with his exactly example too. So I dove in with
[sourcecode language=”bash”]
sudo yum install httpd
[/sourcecode]
to install Apache. With that done I now have Riak & Apache installed on the RHEL EC2 instance. The goal with both of these services is to get them running as the regular local Unix user in a home directory.
With both Riak and Apache installed, time to create a local user directory for each of the respective tools. However, before that, with this version of Linux on AWS we’ll need to create a local user account.
[sourcecode language=”bash”]
useradd -c "Adron Hall" adron
passwd adron
Changing password for user adron.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
[/sourcecode]
Next I switched to the user I created ‘su adron’ and created the following directories in the home path for attempting to get Apache and Riak up and running locally like this. I reviewed the rest of the steps in making the Cartridge w/ Apache and then immediately started running into a few issues with getting Riak setup just like I need it to be able to build a cartridge around it. At least, with my first idea of how I should build a cartridge.
At this point I decided we need to have a conversation around the strategy here. So Bill Decoste, Ryan and some of the other Red Hat team on hand today. After a discussion with Bill it sounds like there are some possibilities to get Riak running via the OpenShift Origin Cartridges.
The Strategy
The plan now is to get a cartridge setup so that the cartridge can launch a single Riak instance. That instance, then with post-launch scripts can then join itself to the overall Riak cluster. The routing can be done via the internal routing and some other capabilities that are inherent to what is in OpenShift itself. It sounds like it’ll take a little more tweaking, but the possibility is there for the near future.
At this point I sat down and read up on the Cartridge a little more before taking off for the day. Overall a good start and interesting to get an overview of the latest around OpenShift.
Thanks to the Red Hat Team, have a great time at the OpenStack Conference and I’ll be hacking on this Cartridge strategy!
References
You must be logged in to post a comment.