There is a trending 'microservice' library called go-kit. I've been using the go-kit library for a while now. The library provide a lot of convenience integrations that you might need in your service: with service discovery with Consul, distributed tracing with Zipkin, for example, and nice logic utilities such as round robin client side load balancing, and circuit breaking. It is also providing a way to implement communication layer, with support of RPC and REST.
| module.exports = { | |
| get: function (req, res) { | |
| res.sendfile(req.path.substr(1)); | |
| }, | |
| _config: { | |
| rest: false, | |
| shortcuts: false | |
| } | |
| }; |
| ticketApp.directive('focusElement', function($timeout) { | |
| return { | |
| restrict: 'A', | |
| scope: { | |
| focusElement: '@', | |
| focusDelay: '@' | |
| }, | |
| link: function($scope, $element, $attrs) { | |
| $scope.$focusElement = angular.isDefined($scope.focusElement) ? $($scope.focusElement): $element; |
| //note: http://www.html-js.com/article/1961 | |
| // Function to download file using wget | |
| var download_file_wget = function(file_url) { | |
| // extract the file name | |
| var file_name = url.parse(file_url).pathname.split('/').pop(); | |
| // compose the wget command | |
| var wget = 'wget -P ' + DOWNLOAD_DIR + ' ' + file_url; | |
| // excute wget using child_process' exec function |
| // Pattern | |
| //Usually, you call a callback as the last thing you do inside a function. | |
| //You might consider it synonymous with return, only JavaScript does | |
| //not halt function execution when it hits it. It can be easy to accidentally | |
| //let execution continue after calling a callback, when you really expected it to end. | |
| //In order to make this easy to spot, and make sure execution stops in the way you expect, | |
| //I recommend returning the callback function call. | |
| // wrong! |
| === Java install === | |
| java zookeeper-3.4.10.jar | |
| sudo apt-add-repository ppa:webupd8team/java | |
| sudo apt-get update | |
| sudo apt-get install oracle-java8-installer | |
| sudo apt install oracle-java8-set-default | |
| export JAVA_HOME=/usr/lib/jvm/java-8-oracle | |
| sudo update-alternatives --config java | |
| sudo update-alternatives --config javac |
| package main | |
| import ( | |
| "encoding/csv" | |
| "encoding/json" | |
| "fmt" | |
| "io" | |
| "io/ioutil" | |
| "log" | |
| "net/http" |
Testing Jenkins flows on your local machine, or running Jenkins in production in a docker container can be a little tricky with a docker-in-docker scenario. You could install Jenkins to avoid any docker-in-docker issues, but then you have Jenkins on your machine, and the local environment is likely going to be a fairly different from the actual production build servers, which can lead to annoying and time-consuming issues to debug.
Build environment differences are precisely why there is a strong argument to be made to run build processes strictly in docker containers. If we follow the philosophy that every build step or action should run in a docker container, even the Jenkins server itself, then we get massive benefits from things like, total control over the build environment, easily modify the build environment without the possibility of adversely effecting other jobs, explicit and strongly controlled tool versions,