LinuxWebLog.com

CodeDeploy with AutoScalingGroups is a bit of a complex mess to get working correctly. Especially with an app that has been working and needs to be updated for more modern functionality

Update the startups scripts with the latest versions from https://github.com/aws-samples/aws-codedeploy-samples/tree/master/load-balancing/elb-v2

I found even the latest scripts there still not working. My instances were starting up then dying shortly afterward. CodeDeploy was failing with the error

LifecycleEvent - ApplicationStart
Script - /deploy/scripts/4_application_start.sh
Script - /deploy/scripts/register_with_elb.sh
[stderr]Running AWS CLI with region:
[stderr][FATAL] Unable to get this instance's ID; cannot continue.

Upon troubleshooting, I found that common_functions.sh has the get_instance_id() function that was running this curl command to get the instance ID

curl -s http://169.254.169.254/latest/meta-data/instance-id

Running that command by itself while an instance was still running returned nothing, which is why it was failing.

It turns out that newer instances use IMDSv2 by default, and it is required (no longer optional). With that configuration, this curl command will fail. In order to fix, this, I replaced the get_instance_id() function with this version:

# Usage: get_instance_id # # Writes to STDOUT the EC2 instance ID for the local instance. Returns non-zero if the local # instance metadata URL is inaccessible. get_instance_id() { TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" -s -f) if [ $? -ne 0 ] || [ -z "$TOKEN" ]; then echo "[FATAL] Failed to obtain IMDSv2 token; cannot continue." >&2 return 1 fi INSTANCE_ID=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/instance-id -s -f) if [ $? -ne 0 ] || [ -z "$INSTANCE_ID" ]; then echo "[FATAL] Unable to get this instance's ID; cannot continue." >&2 return 1 fi echo "$INSTANCE_ID" return 0 }

This version uses the IMDSv2 API to get a token and uses that token to get the instance-id

With that code replaced, the application successfully registered with the Target Group and the AutoScaling group works correctly

Alternatively (and for troubleshooting), I was able to make IMDSv2 Optional using the AWS Console, and via CloudFormation with this part of the Launch Template:

Resources: MyLaunchTemplate: Type: AWS::EC2::LaunchTemplate Properties: LaunchTemplateName: my-launch-template LaunchTemplateData: ImageId: ami-1234567890abcdef0 InstanceType: t4g.micro MetadataOptions: HttpTokens: optional

The post AWS CodeDeploy Troubleshooting appeared first on Brandon Checketts.

At Data Automation, we recently built some stuff for use in ShipStation’s “Auctane Fulfillment Network”, as it is called in the API.
It looks like they refer to it as Send Orders To Fulfillment in their documentation

This is a fairly clever innovation where if the Seller has ShipStation, and their Third Party Logistics (3PL) provider also uses ShipStation, they can essentially “Send To Fulfillment”, meaning it makes a copy of the order in the 3PL’s ShipStation account for them to fulfill the order. Once the 3PL fulfills the order, it copies the shipment information, including Carrier, Service, Tracking Number, and Estimated Delivery Date, back to the seller’s ShipStation account.

It looks like it is still a little convoluted to set-up. The 3PL and Seller need to coordinate some things back and forth via email to begin. But once set up, the seller can simply click the “Send to Fulfillment” button inside their ShipStation account to assign the order to their 3PL. You can also set up automation rules to make that happen automatically depending on the sales channel, sku, and other things

From a technical perspective, the order is duplicated into the 3PL’s system, but not quite exactly the same as if it was pulled from the channel directly.

Its always nice when working with a pleasant customer to troubleshoot new things. With their help we got this sorted out and running smoothly now for our Amazon Custom integration with ShipStation at Data Automation

The post ShipStation’s Auctane Fulfillment Network for 3PLs appeared first on Brandon Checketts.

I announced the HTTP Archive six years ago. Six years ago! It has exceeded my expectations and its value continues to grow. In order to expand the vision, I’ve asked Ilya Grigorik, Rick Viscomi, and Pat Meenan to take over leadership of the project.

The HTTP Archive is part of the Internet Archive. The code and data are open source. The project is funded by our generous sponsors: Google, Mozilla, New Relic, O’Reilly Media, Etsy, dynaTrace, Instart Logic, Catchpoint Systems, Fastly, SOASTA mPulse, and Hosting Facts.

From the beginning, Pat and WebPageTest made the HTTP Archive possible. Ilya and Rick will join Pat to make the HTTP Archive even better. A few of the current items on the agenda:

• Enrich the collected data during the crawl: detect JavaScript libraries in use on the page, integrate and capture LightHouse audits, feature counters, and so on.
• Build new analysis pipelines to extract more information from the past crawls
• Provide better visualizations and ways to explore the gathered data
• Improve code health and overall operation of the full pipeline
• … and lots more – please chime in with your suggestions!

Since its inception, the HTTP Archive has become the goto source for objective, documented data about how the Web is built. Thanks to Ilya, that data was brought to BigQuery so the community can perform their own queries and follow-on research. It’s a joy to see the data and graphs from HTTP Archive used on a daily basis in tech articles, blog posts, tweets, etc.

I’m excited about this next phase for the HTTP Archive. Thank you to everyone who helped get the HTTP Archive to where it is today. (Especially Stephen Hay for our awesome logo!) Now let’s make the HTTP Archive even better!