My Kraken config in config.json
envConfig : {
prod : {
host : "....",
desc : "..."
},
qa : {
host : "....",
desc : "..."
},
}
Can I access this in my dust template as I wanted to dynamically populate my list or would I have to add it again in my context object for the template
I used ContextDump helper to find that the config is not accessible.I think it makes sense too as we should not expose the configuration information to the client side via dust
Related
I have a front-end and back-end separation project I want to redirect to cas from backend, But I got the cross domain problem like this enter image description here.
And I have try fixed it by the user guide: https://apereo.github.io/cas/6.5.x/services/Configuring-Service-Http-Security-Headers.html
Througth it, I have config the follow propertise, but it does not work.
# global config
cas.http-web-request.cors.enabled=true;
cas.http-web-request.header.enabled=true
# client config
"properties" : {
"#class" : "java.util.HashMap",
"corsAllowedOrigins" : {
"#class" : "org.apereo.cas.services.DefaultRegisteredServiceProperty",
"values" : [ "java.util.HashSet", [ "Access-Control-Allow-Origin" ] ]
},
"corsAllowedHeaders" : {
"#class" : "org.apereo.cas.services.DefaultRegisteredServiceProperty",
"values" : [ "java.util.HashSet", [ "Access-Control-Allow-Origin" ] ]
}
}
I am trying to access the environment variables set in a task definition, inside my nodejs app, with process.env.
I use a Dockerfile to create an image of the project, upload it to ECR, then use this image in the task definition.
I set enviroment variables for the nodejs app, inside the Dockerfile, like this:
# Dockerfile
...
RUN ROOT_DIR='/'
RUN PUBLIC_DIR='/public'
...
I have this task definition:
# task_definition.json
...
"environment" : [
{ "name" : "KeyOne", "value" : "KeyOneValue" },
{ "name" : "KeyTwo", "value" : "KeyTwoValue" }
]
...
I am not able to access process.env.KeyOne / process.env.KeyTwo (they are undefined)
I would like to be able to set those environment variables from the task definition and then reference them inside nodejs app with process.env instead of setting them inside the Dockerfile.
Here is a test I just made on my account, using ECS Fargate. All env variables from the task definition are accessible from NodeJS code.
Source Code is at
https://github.com/sebsto/ecs-demo/tree/master/so
TaskDefinition excerpt :
"environment": [
{
"name": "KEY1",
"value": "VALUE1"
}
],
Code extract :
app.get('/', (req, res) => {
res.send(`Hello world<br/>${JSON.stringify(process.env, null, 2)}`);
});
Output :
Hello world
{ "KEY1": "VALUE1", "NODE_VERSION": "10.16.0", "HOSTNAME": "ip-10-0-0-83.eu-west-1.compute.internal", "YARN_VERSION": "1.16.0", "HOME": "/root", "AWS_CONTAINER_CREDENTIALS_RELATIVE_URI": "/v2/credentials/b630982f-dffb-4ccc-9c8b-8311e42b57ab", "AWS_EXECUTION_ENV": "AWS_ECS_FARGATE", "AWS_DEFAULT_REGION": "eu-west-1", "ECS_CONTAINER_METADATA_URI": "http://169.254.170.2/v3/12186f93-de7b-47e3-a096-b0f23d7e0e81", "PATH": "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "AWS_REGION": "eu-west-1", "PWD": "/usr/src/app" }
I'll keep the container is up and running for a few months, you can test yourself at http://52.18.232.75:8080/
In Cloudformation I have two stacks (one nested).
Nested stack "ec2-setup":
{
"AWSTemplateFormatVersion" : "2010-09-09",
"Parameters" : {
// (...) some parameters here
"userData" : {
"Description" : "user data to be passed to instance",
"Type" : "String",
"Default": ""
}
},
"Resources" : {
"EC2Instance" : {
"Type" : "AWS::EC2::Instance",
"Properties" : {
"UserData" : { "Ref" : "userData" },
// (...) some other properties here
}
}
},
// (...)
}
Now in my main template I want to refer to nested template presented above and pass a bash script using the userData parameter. Additionally I do not want to inline the content of user data script because I want to reuse it for few ec2 instances (so I do not want to duplicate the script each time I declare ec2 instance in my main template).
I tried to achieve this by setting the content of the script as a default value of a parameter:
{
"AWSTemplateFormatVersion": "2010-09-09",
"Parameters" : {
"myUserData": {
"Type": "String",
"Default" : { "Fn::Base64" : { "Fn::Join" : ["", [
"#!/bin/bash \n",
"yum update -y \n",
"# Install the files and packages from the metadata\n",
"echo 'tralala' > /tmp/hahaha"
]]}}
}
},
(...)
"myEc2": {
"Type": "AWS::CloudFormation::Stack",
"Properties": {
"TemplateURL": "s3://path/to/ec2-setup.json",
"TimeoutInMinutes": "10",
"Parameters": {
// (...)
"userData" : { "Ref" : "myUserData" }
}
But I get following error while trying to launch stack:
"Template validation error: Template format error: Every Default
member must be a string."
The error seems to be caused by the fact that the declaration { Fn::Base64 (...) } is an object - not a string (although it results in returning base64 encoded string).
All works ok, if I paste my script directly into to the parameters section (as inline script) when calling my nested template (instead of reffering to string set as parameter):
"myEc2": {
"Type": "AWS::CloudFormation::Stack",
"Properties": {
"TemplateURL": "s3://path/to/ec2-setup.json",
"TimeoutInMinutes": "10",
"Parameters": {
// (...)
"userData" : { "Fn::Base64" : { "Fn::Join" : ["", [
"#!/bin/bash \n",
"yum update -y \n",
"# Install the files and packages from the metadata\n",
"echo 'tralala' > /tmp/hahaha"
]]}}
}
but I want to keep the content of userData script in a parameter/variable to be able to reuse it.
Any chance to reuse such a bash script without a need to copy/paste it each time?
Here are a few options on how to reuse a bash script in user-data for multiple EC2 instances defined through CloudFormation:
1. Set default parameter as string
Your original attempted solution should work, with a minor tweak: you must declare the default parameter as a string, as follows (using YAML instead of JSON makes it possible/easier to declare a multi-line string inline):
AWSTemplateFormatVersion: "2010-09-09"
Parameters:
myUserData:
Type: String
Default: |
#!/bin/bash
yum update -y
# Install the files and packages from the metadata
echo 'tralala' > /tmp/hahaha
(...)
Resources:
myEc2:
Type: AWS::CloudFormation::Stack
Properties
TemplateURL: "s3://path/to/ec2-setup.yml"
TimeoutInMinutes: 10
Parameters:
# (...)
userData: !Ref myUserData
Then, in your nested stack, apply any required intrinsic functions (Fn::Base64, as well as Fn::Sub which is quite helpful if you need to apply any Ref or Fn::GetAtt functions within your user-data script) within the EC2 instance's resource properties:
AWSTemplateFormatVersion: "2010-09-09"
Parameters:
# (...) some parameters here
userData:
Description: user data to be passed to instance
Type: String
Default: ""
Resources:
EC2Instance:
Type: AWS::EC2::Instance
Properties:
UserData:
"Fn::Base64":
"Fn::Sub": !Ref userData
# (...) some other properties here
# (...)
2. Upload script to S3
You can upload your single Bash script to an S3 bucket, then invoke the script by adding a minimal user-data script in each EC2 instance in your template:
AWSTemplateFormatVersion: "2010-09-09"
Parameters:
# (...) some parameters here
ScriptBucket:
Description: S3 bucket containing user-data script
Type: String
ScriptKey:
Description: S3 object key containing user-data script
Type: String
Resources:
EC2Instance:
Type: AWS::EC2::Instance
Properties:
UserData:
"Fn::Base64":
"Fn::Sub": |
#!/bin/bash
aws s3 cp s3://${ScriptBucket}/${ScriptKey} - | bash -s
# (...) some other properties here
# (...)
3. Use preprocessor to inline script from single source
Finally, you can use a template-preprocessor tool like troposphere or your own to 'generate' verbose CloudFormation-executable templates from more compact/expressive source files. This approach will allow you to eliminate duplication in your source files - although the templates will contain 'duplicate' user-data scripts, this will only occur in the generated templates, so should not pose a problem.
You'll have to look outside the template to provide the same user data to multiple templates. A common approach here would be to abstract your template one step further, or "template the template". Use the same method to create both templates, and you'll keep them both DRY.
I'm a huge fan of cloudformation and use it to create most all my resources, especially for production-bound uses. But as powerful as it is, it isn't quite turn-key. In addition to creating the template, you'll also have to call the coudformation API to create the stack, and provide a stack name and parameters. Thus, automation around the use of cloudformation is a necessary part of a complete solution. This automation can be simplistic ( bash script, for example ) or sophisticated. I've taken to using ansible's cloudformation module to automate "around" the template, be it creating a template for the template with Jinja, or just providing different sets of parameters to the same reusable template, or doing discovery before the stack is created; whatever ancillary operations are necessary. Some folks really like troposphere for this purpose - if you're a pythonic thinker you might find it to be a good fit. Once you have automation of any kind handling the stack creation, you'll find it's easy to add steps to make the template itself more dynamic, or assemble multiple stacks from reusable components.
At work we use cloudformation quite a bit and are tending these days to prefer a compositional approach, where we define the shared components of the templates we use, and then compose the actual templates from components.
the other option would be to merge the two stacks, using conditionals to control the inclusion of the defined resources in any particular stack created from the template. This works OK in simple cases, but the combinatorial complexity of all those conditions tends to make this a difficult solution in the long run, unless the differences are really simple.
Actually I found one more solution than already mentioned. This solution on the one hand is a little "hackish", but on the other hand I found it to be really useful for "bash script" use case (and also for other parameters).
The idea is to create an extra stack - "parameters stack" - which will output the values. Since outputs of a stack are not limited to String (as it is for default values) we can define entire base64 encoded script as a single output from a stack.
The drawback is that every stack needs to define at least one resource, so our parameters stack also needs to define at least one resource. The solution for this issue is either to define the parameters in another template which already defines existing resource, or create a "fake resource" which will never be created becasue of a Condition which will never be satisified.
Here I present the solution with fake resource. First we create our new paramaters-stack.json as follows:
{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "Outputs/returns parameter values",
"Conditions" : {
"alwaysFalseCondition" : {"Fn::Equals" : ["aaaaaaaaaa", "bbbbbbbbbb"]}
},
"Resources": {
"FakeResource" : {
"Type" : "AWS::EC2::EIPAssociation",
"Condition" : "alwaysFalseCondition",
"Properties" : {
"AllocationId" : { "Ref": "AWS::NoValue" },
"NetworkInterfaceId" : { "Ref": "AWS::NoValue" }
}
}
},
"Outputs": {
"ec2InitScript": {
"Value":
{ "Fn::Base64" : { "Fn::Join" : ["", [
"#!/bin/bash \n",
"yum update -y \n",
"# Install the files and packages from the metadata\n",
"echo 'tralala' > /tmp/hahaha"
]]}}
}
}
}
Now in the main template we first declare our paramters stack and later we refer to the output from that parameters stack:
{
"AWSTemplateFormatVersion": "2010-09-09",
"Resources": {
"myParameters": {
"Type": "AWS::CloudFormation::Stack",
"Properties": {
"TemplateURL": "s3://path/to/paramaters-stack.json",
"TimeoutInMinutes": "10"
}
},
"myEc2": {
"Type": "AWS::CloudFormation::Stack",
"Properties": {
"TemplateURL": "s3://path/to/ec2-setup.json",
"TimeoutInMinutes": "10",
"Parameters": {
// (...)
"userData" : {"Fn::GetAtt": [ "myParameters", "Outputs.ec2InitScript" ]}
}
}
}
}
Please note that one can create up to 60 outputs in one stack file, so it is possible to define 60 variables/paramaters per single stack file using this technique.
I know that it is possible to set the path manually for a CloudFront distribution to point to a subfolder of an S3 bucket.
How do I set the path property using the CloudFormation JSON configuration?
"CloudFrontDistribution" : {
"Type" : "AWS::CloudFront::Distribution",
"Properties" : {
"DistributionConfig" : {
"Origins" : [ {
"DomainName": { "Fn::GetAtt" : [ "DataBucket", "DomainName" ] },
"Id" : "S3Origin",
"S3OriginConfig" : {}
}],
...
I've checked the CloudFormation docs about CloudFront distributions[1], but they don't mention anything about a path property.
I see that path as origin was released (relatively) recently, last December - see this forum post: https://forums.aws.amazon.com/ann.jspa?annID=2806.
Probably CloudFormation didn't pick up this update. Might be worth contacting their support to see when this will be available.
I have a Beanstalk App which has a app_name.elasticbeanstalk.com domain name by default.
I want a domain name like www.app_name.com that can access by bowser, and take following steps.
Register the domain name app_name.com
Set www.app_name.com as a CNAME of the ELB's public DNS.
In this way, I can access the www.app_name.com by the browser.
But, once the browser is loaded, the URL suddenly changes to app_name.elasticbeanstalk.com
I do not want to show the app_name.elasticbeanstalk.com to anyone. Can I just use the www.app_name.com? How?
Help me please.
You can do this by using Route53 and CloudFormation. To do this you would use the Elastic Beanstalk resource inside the CloudFormation template to create your Elastic Beanstalk stack. You would also use the Route53 resource to create your desired domain name. Then inside your Route53 resource you would create an alias that maps to your Elastic Beanstalk endpoint.
This might look something like:
"Resources" : {
"DNS" : {
"Type" : "AWS::Route53::RecordSetGroup",
"Properties" : {
"HostedZoneName" : "example.com",
"Comment" : "CNAME alias targeted to Elastic Beanstalk endpoint.",
"RecordSets" : [
{
"Name" : "example.example.com",
"Type" : "CNAME",
"TTL" : "900",
"ResourceRecords" : [{ "Fn::GetAtt" : ["sampleEnvironment","EndpointURL"] }]
}]
}
},
"sampleApplication" : {
"Type" : "AWS::ElasticBeanstalk::Application",
"Properties" : {
"Description" : "AWS Elastic Beanstalk Ruby Sample Application",
"ApplicationVersions" : [{
"VersionLabel" : "Initial Version",
"Description" : "Version 1.0",
"SourceBundle" : {
"S3Bucket" : { "Fn::Join" : ["-", ["elasticbeanstalk-samples", { "Ref" : "AWS::Region" }]]},
"S3Key" : "ruby-sample.zip"
}
}],
"ConfigurationTemplates" : [{
"TemplateName" : "DefaultConfiguration",
"Description" : "Default Configuration Version 1.0 - with SSH access",
"SolutionStackName" : "64bit Amazon Linux running Ruby 1.9.3",
"OptionSettings" : [{
"Namespace" : "aws:autoscaling:launchconfiguration",
"OptionName" : "EC2KeyName",
"Value" : { "Ref" : "KeyName" }
}]
}]
}
},
"sampleEnvironment" : {
"Type" : "AWS::ElasticBeanstalk::Environment",
"Properties" : {
"ApplicationName" : { "Ref" : "sampleApplication" },
"Description" : "AWS Elastic Beanstalk Environment running Ruby Sample Application",
"TemplateName" : "DefaultConfiguration",
"VersionLabel" : "Initial Version"
}
}
},
More information on using CloudFormation resources can be found here and sample templates can be found here
CloudFormation enables interacting with resources dynamically extremely easy and clean... no to mention completely scripted :)