Commit c0ce15d1 authored by soumyadip's avatar soumyadip

Removing old folder

parent 4bf15c66
Error-Tracking
--------------
.. contents::
Why Error-Tracking is required
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Getting rid of risks to deploy code with bugs
- Helping QA with testing code
- Getting a quick notification about troubles
- Allowing a fast turnaround with bug fixes
- Receiving a convenient display errors in admin panel
- Sorting the errors by user / browser segments
Implementation
~~~~~~~~~~~~~~~
Implementation of Error-tracking,
https://gitlab.ebi.ac.uk/soumyadip/error-tracking-example
Deployed resource,
http://sentry.rdsds.ci-apps.tsi.ebi.ac.uk/ [sample@ebi.ac.uk/sample or Register]
Gitlab Integration
~~~~~~~~~~~~~~~~~~~
Gitlab Integration information can be found at,
https://docs.gitlab.com/ee/user/project/operations/error_tracking.html
\ No newline at end of file
Gitlab to Github pipeline
-------------------------
.. contents::
Code Pipeline
~~~~~~~~~~~~~
There are teams/projects that need their public facing code to be on Github and their in-house code to be in Gitlab.
The Gitlab to Github automated code pull/push can be set up and found at,
https://docs.gitlab.com/ee/user/project/import/github.html
Release Automation
~~~~~~~~~~~~~~~~~~
There are cli tools available to automate release of code from gitlab pipelines to any gitlab or github project by
the use of auth token.
Tools used:
- Github - https://github.com/github/hub
- Gitlab - https://pypi.org/project/gitlab-release/
Implementation
~~~~~~~~~~~~~~
The below .gitlab-ci.yml demonstrates release automation of binary files generated on 'dist/' artifact from build(not shown) stage.
This implementation has been taken from https://gitlab.ebi.ac.uk/TSI/RDSDS/DSDS-Client/blob/master/.gitlab-ci.yml.
.. code:: yaml
release-gitlab:
stage: release
image: python
script:
- pip3 install gitlab-release
- cd dist/
- gitlab-release --server ${GITLAB_SERVER}/${IMAGE_GROUP}/${IMAGE_PROJECT} --project_id ${IMAGE_PROJECT_ID} --description ${CI_REGISTRY}/${IMAGE_GROUP}/${IMAGE_PROJECT}/${IMAGE_NAME}:${CI_BUILD_TAG} dsds-client
artifacts:
paths:
# Must include files passed to gitlab_release
- dist/
only:
- tags
release-github:
stage: release
image: debian
script:
- apt-get update && apt-get install -y hub gettext-base
- mkdir -p /root/.config
- envsubst < hub.template > /root/.config/hub
- hub clone --bare https://${GITHUB_USER}:${GITHUB_TOKEN}@github.com/${GITHUB_REPO}.git cloned-project/
- mkdir -p cloned-project/dist
- cp -r dist cloned-project/
- cd cloned-project
- '[ -z "${RELEASE_MESSAGE}" ] && export RELEASE_MESSAGE="${CI_COMMIT_REF_NAME}\n\nRelease-${CI_COMMIT_REF_NAME}"|| echo "Release message:\n${RELEASE_MESSAGE}"'
- echo -e ${RELEASE_MESSAGE} > release_mssg.txt
- cat release_mssg.txt
- 'hub release create -F release_mssg.txt -a "dist/dsds-client#dsds-client-centos" ${CI_COMMIT_REF_NAME}'
artifacts:
paths:
# Must include files passed to gitlab_release
- dist/
only:
- tags
Gitlab DevOps
===============
This document is based on Gitlab instance deployed in EBI by web production team. The reference of the instance can be found `here <https://www.ebi.ac.uk/seqdb/confluence/x/lI1OB>`_.
.. contents::
Pre-requisites
--------------
- Should have EBI Gitlab account
- Basic knowledge on Docker/Kubernetes
DevOps - Sounds familiar?
-------------------------
**DevOps** can be best explained as people working together to build, deliver,
and run resilient software at the speed of their particular business. DevOps
enables software development (**Dev**) and operations (**Ops**) teams to accelerate
delivery through automation, collaboration, fast feedback, and iterative improvement.
For more, check https://about.gitlab.com/devops/
Why Gitlab for DevOps?
----------------------
There are a lot of DevOps tools out there. As a single application for the entire DevOps
life cycle, GitLab can remove the pain of having to choose, integrate, learn, and maintain
the multitude of tools necessary for a successful DevOps tool chain.
For more, check https://about.gitlab.com/devops-tools/
Auto DevOps
-----------
Auto DevOps provides pre-defined CI/CD configuration which allows you to automatically detect,
build, test, deploy, and monitor your applications. Leveraging CI/CD best practices and tools,
Auto DevOps aims to simplify the setup and execution of a mature & modern software development
lifecycle.
Pros
~~~~~
With Auto DevOps, the software development process becomes easier to set up as every project can
have a complete workflow from verification to monitoring with minimal configuration. Just push your
code and GitLab takes care of everything else. This makes it easier to start new projects and brings
consistency to how applications are set up throughout a company.
Cons
~~~~~
As you can expect, it is not possible for Gitlab to detect and setup deployment for each and every possible
application. There are certain expectation from application that Gitlab required it to be adhered to for Auto-DevOps
to be working without any manual scripting, details on this later. Further, having Gitlab doing all the build and deployment
might not be suitable use-case for everyone.
Pre-requisites
~~~~~~~~~~~~~~
- GitLab Runner
- Base domain
- Kubernetes
- Prometheus
For more, https://docs.gitlab.com/ee/topics/autodevops/#requirements
Expectation
~~~~~~~~~~~
Although it is called *Auto* DevOps, there are some assumptions have been made for Auto Deployment to be working for the application.
The assumptions(and experiences!) are as follows,
- Application should be listening on 5000 port
- Better to write your own Dockerfile, things generally don't work well with hiroku build packs
You can customize some of the parts, more details on https://docs.gitlab.com/ee/topics/autodevops/#customizing
Example
~~~~~~~~
You can find the implementation of Auto-DevOps in,
https://gitlab.ebi.ac.uk/soumyadip/minimal-ruby-app
and sample pipeline in the same project,
https://gitlab.ebi.ac.uk/soumyadip/minimal-ruby-app/pipelines/22970
Security Dashboard, containing test result after running Auto-DevOps tests,
https://gitlab.ebi.ac.uk/soumyadip/minimal-ruby-app/security/dashboard/?project_id=1190&page=1&days=90
Metrics of the running service can be found at,
https://gitlab.ebi.ac.uk/soumyadip/minimal-ruby-app/environments/115/metrics
Tracing
--------
.. contents::
Why Tracing is required
~~~~~~~~~~~~~~~~~~~~~~~~
As on-the-ground microservice practitioners are quickly realizing, the majority of operational
problems that arise when moving to a distributed architecture are ultimately grounded in two
areas: networking and observability. It is simply an orders of magnitude larger problem to network
and debug a set of intertwined distributed services versus a single monolithic application.
What Tracing addresses
~~~~~~~~~~~~~~~~~~~~~~~~
- Distributed transaction monitoring
- Performance and latency optimization
- Root cause analysis
- Service dependency analysis
- Distributed context propagation
Implementation
~~~~~~~~~~~~~~~
Implementation of tracing (Opentracing - Jaegar) can be found in,
https://gitlab.ebi.ac.uk/soumyadip/opentracing-sample-python/
The Jaegar UI is available at,
http://jaegar.rdsds.ci-apps.tsi.ebi.ac.uk/search
Gitlab Integration
~~~~~~~~~~~~~~~~~~~
Gitlab Integration information can be found at,
https://docs.gitlab.com/ee/user/project/operations/tracing.html
\ No newline at end of file
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment