Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP - Merge Une-T INS improvements #5

Open
wants to merge 77 commits into
base: master
Choose a base branch
from

Conversation

franck-boullier
Copy link
Member

This is needed so that the codebase for Unee-T is easier to deploy on different installation.

We are importing some of the improvements made in the Unee-T INS fork.
We are also making sure that we are using variables instead of hardcoded values as much as possible

@franck-boullier
Copy link
Member Author

franck-boullier commented Jan 30, 2020

Pre-requisite:

Dependencies:

We MUST have reviewed, merged and tag released version 0.2.2 of the https://github.com/unee-t/env codebase.
See PR unee-t/env#2
DONE

AWS variables in the parameter store:

We MUST have the correct values for the following variables in the AWS parameter store for each environment: DEV (DONE), PROD (DONE), DEMO (DONE)

  • DOMAIN
  • INSTALLATION_ID
  • STAGE
  • EMAIL_FOR_NOTIFICATION_APIENROLL
  • PRIVATE_SUBNET_1
  • PRIVATE_SUBNET_2
  • PRIVATE_SUBNET_3
  • LAMBDA_TO_RDS_SECURITY_GROUP
  • API_ACCESS_TOKEN
    DONE

Travis CI Setting:

We MUST have the correct values for the following variables in the AWS parameter store for each environment: DEV (DONE), PROD (DONE), DEMO (DONE)

  • DOCKER_USERNAME
  • DOCKER_PASSWORD
  • AWS_DEFAULT_REGION
  • AWS_ACCOUNT_USER_ID_DEV
  • AWS_ACCOUNT_SECRET_DEV
  • AWS_PROFILE_DEV
  • AWS_ACCOUNT_USER_ID_DEMO
  • AWS_ACCOUNT_SECRET_DEMO
  • AWS_PROFILE_DEMO
  • AWS_ACCOUNT_USER_ID_PROD
  • AWS_ACCOUNT_SECRET_PROD
  • AWS_PROFILE_PROD
  • GITHUB_TOKEN

DONE

Issues that are NOT fixed yet:

See #3 and #4

We need to have a solution for these before we merge.

test.sh Outdated
curl -i -X POST \
http://localhost:3000 \
-H "Authorization: Bearer $(aws --profile uneet-dev ssm get-parameters --names API_ACCESS_TOKEN --with-decryption --query Parameters[0].Value --output text)" \
-H "Authorization: Bearer $(aws --profile ins-dev ssm get-parameters --names API_ACCESS_TOKEN --with-decryption --query Parameters[0].Value --output text)" \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why ins here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kaihendry ins is there because we shoulde replace this with a variable but I don't know how we could to that,
See #3 for more details

main.go Outdated
// - Stage (AWS parameter `STAGE`)
// The value for "ins-dev" is also declared in Travis Setting
// it is then passed on as the variable `TRAVIS_PROFILE`
cfg, err := external.LoadDefaultAWSConfig(external.WithSharedConfigProfile("ins-dev"))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way this line works, is that it uses "ins-dev" locally, else it uses the current execution environment.

So imo it should be set to the environment you develop in. E.g. uneet-dev in this case

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So imo it should be set to the environment you develop in. E.g. uneet-dev in this case

The problem with this approach is that this means the code will not be usable "as is" in the Unee-T INS fork <-- this will make things more obscure as the people in charge on the Unee-T INS code will have to know that this repo has to be forked and modified in order for their installation to work as intended.

Much better to use a variable that is already declared in the AWS parameter store and in the Travis settings instead.

See #4 for more details

go.mod Outdated Show resolved Hide resolved
deploy.sh Outdated
@@ -0,0 +1,47 @@
#!/bin/bash
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not configure the AWS environment in travis.yml?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not configure the AWS environment in travis.yml?

Because I'm not sure how this can be done.
Feel free to suggest an alternative to how things are done today

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makefile Outdated
# We create a function to simplify getting variables for aws parameter store.

define ssm
$(shell aws --profile $(TRAVIS_PROFILE) ssm get-parameters --names $1 --with-decryption --query Parameters[0].Value --output text)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the default TRAVIS_PROFILE?

Why is it called TRAVIS_PROFILE and not.... AWS_PROFILE?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the default TRAVIS_PROFILE?

See the code in the travis.yml file on line 46, 53 and 61

Why is it called TRAVIS_PROFILE and not.... AWS_PROFILE?

Because that variable is NOT coming from AWS, that variable is defined when travis.yml runs and because its value will be based on the Travis CI settings for this environment.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea with a Makefile and most other robust software is that you define a default that can be overridden.

These are defaults: https://github.com/Unee-T-INS/lambda2sqs/blob/master/Makefile#L1-L5 and the style you should emulate here, else when you run make it won't work.

Copy link
Member Author

@franck-boullier franck-boullier Jan 31, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea with a Makefile and most other robust software is that you define a default that can be overridden.

These are defaults: https://github.com/Unee-T-INS/lambda2sqs/blob/master/Makefile#L1-L5 and the style you should emulate here, else when you run make it won't work.

I understand the idea but we've not been able to implement that using variables instaed of hardcoded values.
In your example: https://github.com/Unee-T-INS/lambda2sqs/blob/master/Makefile#L1-L5
We need to replace the hardcoded values

PROJECT = lambda2sqs <--- this is OK  since this is the hardcoded name of the project
STACK_NAME ?= $(PROJECT) <--- this is OK (it's a variable)
AWS_REGION = ap-southeast-1 <--- this does NOT seem to be OK: it should be a variable
DEPLOY_S3_PREFIX = lambda2sqs <--- this is OK  since this is a hardcoded prefix related to the name of the project (question: why not use the existing PROJECT variable since the value is the same?)
AWS_PROFILE = ins-dev <--- this does NOT seem to be OK: it should be a variable

Copy link
Contributor

@kaihendry kaihendry Jan 31, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are variables that can be overridden.

DEPLOY_S3_PREFIX can be the PROJECT variable.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are variables that can be overridden.

I'm sure this is true but you've never explained HOW they can ACTUALLY be overridden...
If you can do that (show HOW they can be overridden) then I think we'll have made huge progress.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I thought I showed in the call / screen share.


[hendry@t480s m]$ make
foobar
[hendry@t480s m]$ make A_VARIABLE=somethingelse
somethingelse
[hendry@t480s m]$ cat Makefile
A_VARIABLE := foobar

all:
        @echo $(A_VARIABLE)

@franck-boullier
Copy link
Member Author

franck-boullier commented Jan 31, 2020

Build is failing with this error:
image

@kaihendry mentioned in some of our conversation that this might be solved by setting a parameter GITHUB_TOKEN in the Travis CI setting for this repo

The problem at this stage are:

  • there IS a parameter GITHUB_TOKEN already setup in the Travis Settings for this Repo.
  • We have no information about where/how we can find the value for this variable GITHUB_TOKEN <-- we are unable to update it.

@kaihendry more information about how/where we can find the value for the GITHUB_TOKEN variable will be helpful.

@kaihendry
Copy link
Contributor

@franck-boullier
Copy link
Member Author

https://help.github.com/en/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line I believe shows how to create a GITHUB_TOKEN

Which one do I need to choose?
image

@kaihendry
Copy link
Contributor

You don't need to choose any, the idea with GITHUB_TOKEN is that just identifies you to facilitate the download. It doesn't need capabilities to access repos IIRC.

You could just copy it from the unee-t travis configuration too btw.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants