The purpose of python-template project is to provide developer reference guideline to create python project. This project goes further and sets an example for creating all the necessary pieces of information for deployment to kubernetes cluster and Jenkinsfile for building jenkins job. This is complemented by Jenkins job which can be found at https://jenkins-master.socinternal.com/job/templates/job/jenkinsfile-python-example/ or logging in to jenkins https://jenkins-master.socinternal.com and then navigating to "Jenkins Template" and then clicking "jenkinsfile-python-example".
This is to be noted that this is just the reference implementation for developers around how to setup project and get started. Developers need to clone the bit bucket repository for creating their own project. Same stands true for jenkins job as well. They need to copy the jenkins job and create their own jenkins job in dev area of project they are assaigned to.
No modification is to be made to bit bucket repository for this template and the jenkins job. Though any modifications and feature addition requests are welcomed.
The project has following tree structure.
PYTHON-TEMPLATE ├───app │ ├───configs │ ├───consumers │ ├───requirements │ ├───tests │ │ └───fixtures │ └───workers └───ops └───scripts
The root of the project contains files such as: .gitignore, .dockerignore, Dockerfile, Jenkinsfile, deployment.yaml
.gitignore specifies intentionally untracked files that Git should ignore. A project normally includes such .gitignore files in its repository, containing patterns for files generated as part of the project build. Patterns read from $GIT_DIR/info/exclude .
.dockerignore prevents files from being added to the initial build context that is sent to the docker daemon when you do docker build , it doesn't create a global rule for excluding files from being created in all images generated by a Dockerfile.
Dockerfile is a text document that contains all the commands a user could call on the command line to assemble an image. Using docker build users can create an automated build that executes several command-line instructions in succession.
Jenkinsfile is a text file that contains the definition of a Jenkins Pipeline and is checked into source control. This encapsulates all the logic worked out by jenkins job.
deployment.yaml is a yaml file that replaces traditional kubectl run command. This application includes kubernetes-worker-role. You need to make sure it accesses appropriate to your role. Or get your kubernetes role created and replace with kubernetes-worker-role
Hard work is done for you. For dev jobs, on push, it triggers jenkins job as defined in Jenkinsfile. In this example, jenkins job would read Jenkinsfile and follows instructions. It checks out code from develop branch, builds docker image, pushes the docker image to container registry and the last step pulls docker image from registry and deploys to kubernetes cluster.
The "pull and deploy" workflow is fine for dev jobs but in UAT and the PRODUCTION jobs these should be different steps. As you might to build and store image to repository at different time then when you wish to deploy it. An excellent example for this use case may be QA passing of the build after thorough checking and giving a green signal to deploy.
Navigate to kubernetes dashboard and hit service end point for the application. At the timing of writing this, it looks like:
http://aba82634ad78a11e6bace028e51f1df5-1593915368.ap-southeast-2.elb.amazonaws.com:5050/
and shows "Hello World" message.
http://aba82634ad78a11e6bace028e51f1df5-1593915368.ap-southeast-2.elb.amazonaws.com:5050/s3
shows files retrieved from s3://isentia-testing-sqs-bucket bucket location.
The relevant code is given at app/sqs.py