Today, the web is organized by webpages and keywords, treating important entities like people and companies as metadata

Node.io

nodeio

Find the right React Unit Test Tools Pick up the right Unit Test tool for React Component is confusing, as the result of from google, hundreds of combination of chai+jsdom, jest+mocha, mocha+enzyme etc, come up to my eyes. Hey, Google, Can you just tell me the BESTest one and don’t make me think? ‘react unit test’ Unit Test of React Component is a bit different, rather than verifying output of functions, Unit Test in React requires 4 extra testing purpose ( ): Ref Artem Testing basic component rendering Testing props Testing events Testing event handlers Two most popular options are and . After spending hours in try out those tools, I end up in the great Jest Enzyme Airbnb open sourced Enzyme. jest is a JavaScript test runner maintained by Facebook. Included performance, mocking, , code coverage, sandbox. Jest snapshot When using Jest to test a React or React Native application, you can write a snapshot test that will save the output of a rendered component to file and compare the component’s output to the snapshot on subsequent runs. This is useful in knowing when your component changes its behaviour. jsdom + Mocha provides React the required DOM to render to, implementing a suitable subset of browser’s DOM implementations entirely in node/io.js. jsdom Enzyme is a library that wraps packages like , and to create a simpler interface for writing unit tests (work with shallow rendering). React TestUtils JSDOM CheerIO Example This is the of the example using E to test React component: git nzyme Install $ git clone https://github.com/wahengchang/react-test-must-know$ npm install Run Tests $ npm test > jest**PASS ** src/__tests__/**simpleFoo-test.jsPASS ** src/__tests__/ Foo-test.js **Test Summary**› Ran all tests. (7 total in 2 test suites, run time 2.08s) › 7 tests passed Should know 1.Verfity values of state/proprs in a component const wrapper = shallow(<ComponentName />);

expect(wrapper.state().data).toBe('something');expect(wrapper.props().data).toBe('something'); 2.Verfity values of tag in a component const wrapper = shallow(<ComponentName />);

expect(wrapper.find('h4').length).toBe(1);expect(wrapper.find('h4').at(0).text()).toBe('Something'); 3.Simulating click event of a button const wrapper = shallow(<ComponentName />);

expect(wrapper.state().data).toBe('state1');wrapper.find('button').simulate('click');expect(wrapper.state().data).toBe('state2'); Trick Asserting style ( ) from wrapper.find('.myClassname') .get(0).style;   expect(containerStyle).to.have.property('opacity', '1'); Asserting class name ( ) from const span = mount(<Test />).find('span');expect(span.html().match(/style="([^"]*)"/i)[1]).toBe('color: #000;'); *Remark Shallow Rendering testing a component as a unit, import { shallow } from 'enzyme';const wrapper = shallow(<MyComponent />); Full Rendering Components that may with DOM APIs, or may require the full lifecycle in order to fully test the component (i.e., etc.) interact componentDidMount i mport { mount } from 'enzyme';      const wrapper = **mount**(<MyComponent />); Static Rendering It is used to render react components to and analyze the resulting HTML structure. static HTML import { render } from 'enzyme';const wrapper = render(<MyComponent />); enzyme.wraper A wrapper refers to the enzyme wrapper class that provides the API ( ). more wrapper. (Foo)wrapper. ('.icon-star')wrapper. ('button').simulate('click')wrapper. (<div className="unique" />)wrapper. ().datawrapper. ().data find find find contains props state Reference: https://github.com/wahengchang/react-test-must-know http://blog.iannelson.systems/12-reasons-why-i-love-unit-tests/ https://github.com/facebook/jest/blob/master/examples/snapshot/Link.react.js https://github.com/facebook/jest https://facebook.github.io/jest/docs/tutorial-react.html https://github.com/facebook/jest/tree/master/examples/snapshot https://www.codementor.io/vijayst/unit-testing-react-components-jest-or-enzyme-du1087lh8 https://hackernoon.com/testing-react-components-with-jest-and-enzyme-41d592c174f#.d3lo5wnl5 http://airbnb.io/enzyme/docs/api/shallow.html

[React] Review: Component Unit Test is easy

Summary In this article, you’ll learn Anatomy of Kubernetes Pods and NodePort Service example with Running Containers in Pods. Introduction to Pods Kubernetes revolves around the pods. So, you have to know what these pods are. Pods are the run time environment using which we deploy the applications. It is an atomic unit of scheduling in Kubernetes. One or multiple containers deployed together on a single host is called as a pod. We will see how pods are deployed and scaled inside Kubernetes cluster. Now I am going to explain about the Kubernetes Pods and NodePort Service with Running Containers in Pods and Connecting to Running Containers in Kubernetes Cluster Setup The Kubernetes cluster setup that I am using for this demo consists of one master node and 3 worker node VMs. All these 4 VMs are running on Goggle cloud with centOS. We will be connecting to these VMs using a cloud shell. Let’s check the status of these nodes by running get nodes command. kubectl As you can see from the command output, we have 1 master and 3 worker nodes. All 4 nodes are ready and running successfully. Now we will review the pod manifest file with nginx container. Go to the pod working directory where we have kept the manifest file. I have created one manifest file for the demo. Most of the Kubernetes objects manifest file, the above pod manifest file consists of 4 top labels required field i.e. , , , and . So, we should have them in our yaml config file. apiVersion kind metadata spec : This defines the version number which these Kubernetes objects belong to. So, the API version of pod is v1 here in our case. apiVersion : The kind of object which we are going to create. In our case, this is a pod. Kind : This section consists of two fields. One name and other is a label. Here name of the pod is nginx pod. Metadata : This is an optional field. Labels are used to logically group all related pods together for displaying and managing. Tier is for specifying the env. In our case it is dev. Labels help for filtering. Suppose there is 1000 number of pods running inside our Kubernetes cluster and we want to filter only nginx pods then these labels come very handy in this type of situation. Labels : here in this nginx example, I am deploying nginx container from Docker hub. The name of the container we define here is “nginx-container”. Image I am using here is nginx. Since I am not giving here any specific version, it is going to download and install the latest version. You can also give the environment variables port number and volumes for this nginx container. Spec : Pod Config Creation We will deploy the pods using kubectl to create command. Let’s create the nginx pod. First, check if there are already any pods running inside the Kubernetes cluster. As you can see that there are no pods running. Now we will create the pods using create command followed by the name of the manifest file which I have already mentioned above. kubectl Here the is our manifest file and our pod got created after issuing the above command. Now again we will check if pod is created or not by issuing below get pods command: nginx-pod.yaml Here you can see that nginx pod is successfully running. Now as there are 4 nodes inside the Kubernetes cluster, we have then how can we know that on which node this nginx pod is running on. We can get the info by getting pods commands with a wide option. Now in the above image, you can see that the IP address of the pod and it is running on the worker 3 node. Suppose we have lost our manifest file or deleted, and we have the nginx pod running inside our Kubernetes cluster. Then we can print the nginx pod details that are running from the yaml file. Now you can from the above image that the nginx pod configuration in yaml format. This is useful when we want to display every minor detail of running an object. Now to see the complete details of the pods issue command: “ ”. Then you can see all the details about the pods: kubectl describe pod nginx pod | more You can see above the detail info about the pod that it is running fine on the worker node with the IP address detail and event details. We can also expose this pod using NodePort service. We will be discussing more details about the Kubernetes services like NodePort, Loadbalancer, and clusterIP services in our other Kubernetes services blog. Expose the pods using Nodeport service: Once the app is exposed to the outside world on to the internet, then we will access a sample html webpage and also the default nginx webpage using node IP and node port from any web browser. Node IP: it the external IP address of any master node or any worker node inside the Kubernetes cluster. Besides accessing the webpage from the internet, we will also try to access that sample html webpage internally from the worker nodes using Kubernetes cluster using pod IP. To create test.html page inside nginx-pod root directory, we need to get inside the pod first. Here hostname is the pod name I have given i.e. . Now let’s create a sample “ ” page inside the nginx root directory. nginx-pod test.html test.html: This is a very simple html file and we are just printing some header. Now let’s expose this through NodePort Service. So now I will run the command. nginx-pod So, now we have successfully exposed the nginx pod to the outside world using NodePort Service. Now we need to know the node port number on which this nginx webpage is exposed to the outside world. We can get that info by running describe command. Svc option is for the nodeport service name of the nginx-pod. You can see above the node port is . So, to access the webpage from the web browser, we need node IP and node port. This node IP is the external IP address of the Kubernetes master or any worker node inside the Kubernetes cluster. 30758 As we have already checked that nginx pod is running on worker node 3, so let’s take the worker node 3 IP. Here external IP is yellow marked i.e. . Now we have our node port . So, we have everything to access the nginx page on the browser. 35.196.57.193 30758 Test the node port IP: Now go the browser and access the URL with node port IP and port like below: As I mentioned earlier Node IP is a publicly routable external IP of any worker node or a Kubernetes master node. In our case, it is worker 3 external IP address. We got the node port by exposing the nginx pod using node port service. Now let’s access our test.html webpage that we have created inside the pod. Here we can see that we have successfully accessed the html webpage externally on internet. Note: You can able to access a webpage using your master node or any other worker node’s external IP address but with using  the same node port. Now let’s access the same web page internally from Kubernetes cluster. For this, we need pod IP and port number. We will get that info from the to describe command: So, here the endpoint you can see is the pod IP and port. Now copy the IP and port and issue a curl command: Now we can see that we are successfully accessing the default nginx webpage. Now let’s try accessing the html webpage with pod IP and port number: : Pod Delete Operation Here is my demo, I have created two objects i.e. pod and NodePort service. Now let’s delete the pod and the service with the delete command followed by pod name and service name like I have done in below: We will see now if it deleted successfully or not by below commands: Here you can see above that the two objects deleted successfully. : Kubernetes Services Anatomy Imagine that we have to deploy a web app. typically, webapp consists of UI part and backend database. So how do we expose the frontend web app to the outside world? And how do the UI part will connect to the backend database? Another thing is that when pods get recreated their IP address changes then it will be difficult to connect when the pods’ IP changes dynamically. We can address above problems using Kubernetes Services. Suppose, we have a front-end web app and a backend DB. Some users are trying to access the web app. As we know every pod in Kubernetes has a unique IP address. These pods last for a very short time. There are various reasons why pods die. But when the controller recreates the pod then the pod will get the new IP address. So, whenever pods get recreated then it gets a new IP address. This creates a problem. Let’s say backend pods provide some kind of functionality to frontend pods inside Kubernetes cluster, then how does the frontend pods keep track of the backend pods. Another thing is you know every app is made up of Microservice. Each of the Microservice is deployed to the individual pods. So, to work this app properly, all the individual Microservice which are present in the pods need to be connected and communicated together. The next question is how these apps do are exposed to end-user who are trying to access through the internet. To solve all the above problems Kubernetes Services come into picture. Kubernetes Service Service is a way of a grouping of pods that are running on a cluster. Services provide some of the important features that are standardized across the cluster such as load balancing, service discovery between apps and features to support zero-downtime app deployment. These are cheaper and we can have as many Java web development services possible within our cluster. One of the services to solve the above problem is “NodePort Service” NodePort Service real-time example: We have a node here in the above image. And inside that we have a front-end web app. pod. Which is deployed on it with an IP address. There are users who are trying to access this application over internet. Now there are two challenges we have. First, we have already discussed that we cannot trust the pod IP as it changes dynamically after recreation. Second is there are no connectivity between user and pod. So, to address these two challenges, Kubernetes provides the “Nodeport” Service. Using NodePort we can expose the service on node IP at a static port which is called nodeport. Here we are talking about two things. One is node IP and other is NodePort. So, as you can see above currently there is a web app running on frontend pod. So, to expose this app to the outside world on internet, we need to create a service of type NodePort. So once the node port service is deployed then the application is exposed on Node IP which is here 192.168.1.1. And the node port that we will mention in the manifest file is 31000. There is a limitation here. If we are defining the node port manually inside a manifest file, then make sure you define the node port in the range of 30000 to 32767. If we don’t mention in the manifest file, then Kubernetes will assign an unused node port within that range dynamically. (Node port is a port where the pod is running).Node IP is a static IP to access the app from the browser. The second port you can see in the above image is “80”. This is the target port on the service itself. Another port i.e. service port is the port on actual pod where the webapp is running. Typically, the service port and target port are the same. To remember these ports, you have to look at the service side. Let’s assume you are on the service and port on the service is just referred to as the port. The requests are getting forwarded to the target port which is on a pod. NodePort service example Demo Create 4 Nodes in Google cloud. Like below: (See our blog how to install Kubernetes and create  nodes on Google cloud ) I will be connecting to the above VMs using a cloud shell. Check the status of the nodes if they run successfully using the command (kubectl get nodes). First, check if no pods and deployment and services are running inside our Kubernetes cluster using ( kubectl get pods/deploy/service). So that we can have a clean Kubernetes cluster setup. Create a nodeport working directory inside the master node with ‘mkdir’ command. Then go to that working directory. Here my working dir is “nodePort-svc”. Here I have created two yaml manifest files inside the working directory you can see that. : Nginx-deploy.yaml This is a simple nginx deployment manifest file where I am going to deploy one replica of nginx container 1.7.9. Please note pod labels I have used here are “nginx-app”. We have to use these exact pod labels inside the nodeport service manifest file. This ngix-app pod runs on port 80. : Nginx-svc.yaml Nodeport service file contains 4 top sections. They are “api version”,”kind”,”metadata” and”spec”. Service is part of an initial stable release. So, the API version is “v1”. The kind of object I am creating here is the “Service”. I have defined the name of the service as “my-service “under the metadata section. I have also provided labels to this service, but this is an optional field. For simplicity, I am using the same labels as pod labels. In the spec section, all core ports lie. This spec section contains 3 important things i.e. “selector”, “type” and “ports”. The purpose of the selector is to define the way this NodePort service selects the pods that it needs to manage. This is done using the pods labels. So, I have included the exact pod label under the selector section. Type: this is the type of service we are going to create. Here the type of the service is “NodePort”. Ports: in this section, we define the ports. Here you can see I have defined 3 ports. 1st one is “nodePort”. We can define the nodePort manually here or else Kubernetes will assign the port automatically while creating the node port service. Here I have given is 31111. So, Kubernetes will expose the nginx application on every worker node and master node inside the Kubernetes cluster on the internet using this nodePort. So an external client can call the service by using the external IP of a node and nodePort. Port: This port is the port on the service itself. Here I have given port as “80” TargetPort: This is a port on the container where the application is running on. The request is being forwarded to the members of pod onto the specified port by the targetPort here i.e. 80 here in our manifest file. Generally, port and target ports are the same numbers. If we don’t specify the target port here, then it defaults to the value of the port fields. Deployment Now we need to create the deployments using the deployment manifest file which I have already created inside my working directory of nginx service app. Issue the below command: The app deployed successfully. Now I need to expose the application to the outside world and for that I will do that with the help of NodePort service. Create NodePort service with the below command using our  service file i.e. “nginx-svc.yaml file”: Now the service created successfully. Now let’s display the objects we have created so far with the below commands: As you can see “my-service” of type nodePort created successfully. Also, you can see there is one pod created with the deployment and that pod is running successfully on the worker node 1.  Now let’s create a sample html webpage inside our working directory by going into the pod. Let’s get inside to the pod with the below command: Now let’s create a sample html page inside our working directory. : Test.html Now I will try to access this html page internally using pod IP and port. Now let’s find our pod IP by issuing below command: Now we know the pod IP and let’s call this using curl command: Now we can access the page successfully. Now I will try to access the same page using internal nodeport cluster IP. Now to find the cluster IP, we need to run the below command: So, using this nodeport cluster IP, we can access the same html webpage using curl command: The main part is we will access this same webpage externally from the internet using the node IP and node port. We know the node port we have configured already is “3111”. Now let’s get the external IP of a node in the goggle cloud dashboard inside our cluster. Let’s take the IP of the master node i.e. here 34.73.122.126. Now we will access our html webpage externally from the browser using this node IP(34.73.122.126) and node port(3111) So, you can see above, we can successfully able to access it. You can also access any of the worker node IP and node port and this will work fine. Conclusion Here, I have explained the most important features of NodePort Services. Also, I have demonstrated running Containers in Pods and Connecting to Running Containers in Kubernetes. References https://kubernetes.io/docs/concepts/services-networking/connect-applications-service/ https://kubernetes.io/docs/tutorials/kubernetes-basics/explore/explore-intro/

Introducing NodePort Service in Kubernetes

Manually restarting Node.js application is a tiring and tedious job. is the best solution available to autorestart a nodejs app server in development mode. Nodemon Step 1 Organize the source directory and initiate it with an or or or any other convention you use to bootstrap a Node.js server. src app.js index.js server.js Update the file accordingly by adding a script. package.json start Step 2 Add or any other framework as dependency to bootstrap a minimal server. express Code for a minimal server: In first terminal window start the server: In second terminal window, request the url to test if the api is working and to see the response message: Now if I change the response message, I have to restart the server to get the desired result: Use to stop the currently running server and restart it by using the same command before: . Ctrl + C npm run start Using the curl command again from terminal window we get the desired result: This whole process is repetitive will slow your development of any package or application. Better solution is to use . nodemon Step 3 Add nodemon as : devDependency Step 4 Make another script under npm scripts in file: dev package.json Now run and request using curl command, we will see the last familiar result: $ npm run dev If I change the response message in file back to , this time I don't I have to restart the server since is watching for the changes using inside the src directory, through its parameter. If I use the curl command again, the result is familiar with the update index.js Hello World nodemon --watch One can verify by observing the log messages in the terminal window where nodemon is running: To stop the nodemon process, use . Ctrl + C Full Source at . this Github Repository If you find this article useful, please clap 👏 . Thank you!

Setup Nodemon to auto restart Nodejs application server

Podiums discussion at NodeConf Barcelona 2017 It was with immense passion and pleasure that the team here at worked tirelessly to bring another . blended.io NodeConf to Barcelona But, this isn’t about us, it’s about the event itself. So, without much further ado, let’s get down to the retrospective. Let’s see what we did well, and what we can do better next time. By The Numbers NodeConf Barcelona 2017 was the second NodeConf to be hosted in Barcelona (the third, if you count ). In 2015, the first NodeConf Barcelona attracted roughly 100 attendees, with 13 speakers, mostly from Europe, with 4 out of the 13 speakers (31%) being female. WeNode This year, NodeConf Barcelona attracted 150 attendees from 15 countries. We had 12 speakers, from inside and outside the European Union, with 5 out of 12 speakers (42%, an 11% increase) being female. But it wasn’t just by the numbers that NodeConf Barcelona did well in 2017, the feedback from both attendees and speakers was also phenomenal. Really an awesome couple days connecting with the people at @NodeConfBcn — thanks for a fantastic event. Until next time @PatrickHeneise ! — admc (@admc) April 9, 2017 @abrausewetter @NodeBCN @PatrickHeneise it was a fantastic conference with a sublime organization! — Luca Maraschi (@lucamaraschi) April 8, 2017 The Inspiring Talks This year, we had a lineup of 12 amazing speakers sharing their learnings and thoughts on a variety of NodeJS and DevOps topics. As always, we strive for diversity and greater representation at our conferences. So, we were very happy to welcome speakers from outside of Europe, as well as have 5 out of 12 speakers (42%) be female. Hopefully, next year, we’ll cross the 50% boundary on that one! Jan Lenhardt: Kill All Humans Jan opened the day with his ‘scarily’ titled talk: “Kill All Humans”. Luckily, all the attendees survived this informative session about development tool automation. Whilst you should watch Jan’s session yourself online, our favourite takeaways were: Hauptversionsnummernerhöhungsangst: The German word for fear of increasing the major version number Semantic Versioning makes the ecosystem and library usage reliable as you can see by the number if this is a breaking change to your code Greenkeeper keeps your libraries up-to-date Thanks all for being a great audience at @NodeConfBcn . If you have any question about @greenkeeperio @hoodiehq or @couchdb , find me ✌️ — Jan Lehnardt (@janl) April 7, 2017 Watch the video Myles Borins: Canary in the gold mine — smoke testing “Kill All Humans” and now canaries? I’m starting to see a worrying theme here… But, Myles kept it light with his insightful talk about smoke testing, and how you can test for potentially project-breaking changes in your code. “Dear Diary, today we broke the internet.” — Best diary I’ve heard of, amazing stories of a release manager. View the and review the source on slides Github Watch the video Bryan English: Signet: Safely Curl Pipe Bash. No Seriously! In his session, Brian English talks about Signet, a tool for safely managing packages and installing software. Watch the video Anna Henningsen: Node.js � Character Encodings Get an understanding of UTF-8 and how character encodings can break your software. Even in the Emoji-rich times of today. Anna shares her best practices for storing and transmitting strings in their Unicode form. and View the slides watch the video Irina Shestak: knock-knock-who-there-file-compression-talkFINAL2.tar.trz.bz2.gz In her talk, Irina shares some great knowledge about speeding up your NodeJS applications and sites with the effective use of compression. and View the slides watch the video William Kapke: The Node.js Organization: Behind the scenes What’s going on behind the green curtains of Node.js? What’s the Node Foundation? How can you get involved? William answers all of your questions in this fascinating and informative talk. Watch the video Thomas Watson: Build your own JavaScript powered radio Bring back the radio! And hack your car keys. Make Javascript interact with the real world with this talk about hardware-hacking radio frequencies by Thomas Watson. and View the slides watch the video How will bulletin boards and news systems work in the world of the distributed web? In his talk, Luca shares how he has built a scalable pub/sub system using UpRing, and how you can do it too. and View the slides watch the video Daniela Matos de Carvalho: Let’s play with HTTP/2 HTTP/2 isn’t coming up next, it’s already here. Prep your servers and understand how to provide better web performance with the next generation of this vital protocol. and View the slides watch the video Useful links: Logan McDonald: Using Node in a serverless world… Can you run your application or service without the high costs of servers and infrastructure? Logan thinks that some of you can, and that most of us will be able to in the future. See how in her forward-looking talk. Watch the video We’ve all heard that chatbots and conversational UIs are the future, but how do you build them? Eva was kind enough to share with us her insights into the creation of conversational bots and how you can start building them today with Amazon Lex. It dawned on me how hard it is to run an event with laid back atmosphere AND Shinkansen punctuality! Congrats @PatrickHeneise @NodeConfBcn — eva (@lavigi) April 10, 2017 or View the slides watch the video James Snell: The Node.js Process, Making decisions that impact a massive ecosystem How do you make decisions that affect millions of creators and consumers worldwide? It turns out, as James Snell shares, with a little care and a lot of planning. Watch the video Collaborator Q&A In this short session, some of our 2017 speakers and Node collaborators answer your questions about NodeJS now and in the future. Watch the conversation Transparency Report For the sake of transparency, here are the financials for NodeConf Barcelona 2017. If you’d like more information about these expenses, or some advice on financing your own conference, we’re happy to have a chat. Please reach out to nodeconf@blended.io. Please see the entire report (then scroll to the end). here Conclusion And Thank You First of all, a big thank you to the and its team to host and support us! Mobile World Centre If we had to describe NodeConf Barcelona 2017 in one word, it would be “Inspiring”. It was truly great to see so many people attend this years conference. To bring together great speakers from around the world to talk about a subject close to their heart. And to meet so many people excited about NodeJS and its future. A thanks must go out to all of those who made this year’s conference possible. A thank you to all of our speakers, to our sponsors, to the team at Blended.io who organised the conference, and to those attendees who made the event possible and so enjoyable. We couldn’t do it without the hard work and contribution of this great community. This year’s conference was a great success, so to keep up to date on the next NodeConf Barcelona. please follow us on Twitter We at are incredibly excited and passionated about the potential innovative leaps for software design and engineering in fintech, investtech and industry 4.0. Thanks for reading. blended.io Get in touch! Stay on the edge about innovation, experience design or engineering! No spam and . Get hands-on articles worthwhile content only Originally published at blog.blended.io on April 11, 2017.

NodeConf Barcelona 2017, A Retrospective

I like being productive and always looking for tools to work efficiently. Now I am working on a project, auto-watch setup is different on (restart server when file changed) and (to build static file when changed). However the idea of is shared same on both server and client sides. There are much enough tools for auto-watch: webpack, grunt, gulp, nodemon, etc, and auto-build: webpack, grunt, gulp, browserify etc. React isomorphic server side client side isomorphic React component Find the right tool to do the right task, playing with them 1 after 1, this is the of this example, hope it is helpful. git 1- Create a simple Express server //app.jsvar express = require('express')var app = express() app.get('/', function (req, res) {res.send('Hello World!')}) app.listen(3000, function () {console.log('Example app listening on port 3000!')}) 2- Run a Express server And auto-watch is not on yet. $ node app.js Example app listening on port 3000! 3-Run the same server by nodemon $ npm install **--save-dev nodemon   $** ./node_modules/nodemon/bin/nodemon.js app.js [nodemon] 1.11.0[nodemon] to restart at any time, enter `rs`[nodemon] watching: *.*[nodemon] starting `node app.js` Example app listening on port 3000! 4- Run nodemon with Config files Nodemon supports local and global configuration files. These are usually named nodemon.json. An alternative local configuration file can be specified with the option. --config <file> see , sample nodemon.json Run with the sample nodemon.json $ ./node_modules/nodemon/bin/nodemon.js app.js --config nodemon.json [nodemon] 1.11.0 [nodemon] reading config /Users/userA/nodemon-example/nodemon.json [nodemon] to restart at any time, enter `rs` [nodemon] ignoring: .git .nyc_output .sass-cache bower_components coverage /Users/userA/nodemon-example/node_modules/**/* .git node_modules/**/node_modules [nodemon] watching: test/fixtures/**/* test/samples/**/* [nodemon] watching extensions: js,json [nodemon] bind restart -> `osascript -e 'display notification "App restarted due to: '$FILENAME'" with title "nodemon"'` [nodemon] starting `node --harmony app.js` [nodemon] child pid: 6166 [nodemon] watching 3 files Example app listening on port 3000! 5- setup package.json with nodemon script //package.json "scripts": {"start": "node app.js","dev": "echo 'run dev' & npm start","test": "echo \"Error: no test specified\" && exit 1","nodemon": "./node_modules/nodemon/bin/nodemon.js --config nodemon.json --exec npm run dev "}, Run $ npm run nodemon Remark: execMap In config file, define your own executables: nodemon.json {  "execMap": {     "pl": "perl"  }} Triggering events when nodemon state changes In config file, define action for event (Read more ) : nodemon.json EventList {"events": {"restart": "osascript -e 'display notification \"app restarted\" with title \"nodemon\"'"}} Reference: https://github.com/remy/nodemon#nodemon https://github.com/wahengchang/nodemon-example

[Nodemon] Auto-Watch-Reload Node.js file

Previously… https://awstip.com/reducing-eks-windows-node-5-min-start-time-to-90s-eks-windows-bootstrapper-4314f72367a0?embedable=true I threw in some tricks I used to make our Windows EKS nodes start in 90s rather than the 5 minutes a standard EKS Windows node takes. I introduced you to the git repo eks-windows-bootstrapper - the application replacing the AWS-provided configuration scripts for EKS Windows. https://github.com/atg-cloudops/eks-windows-bootstrapper?embedable=true In today’s story, I will walk you through how to make your Windows nodes take ~30s to start! Recap In the previous story, we got to the point where our start times looked like this: Let’s take a closer look at our latencies now: In order for us to get better launch times, we now have 2 areas where we can improve timing Windows Startup Configure Network/Start K8s Services Improving Windows Startup Performance As we are using the AWS Image Builder (https://aws.amazon.com/image-builder/) to build our custom AMIs as discussed in the previous story, any changes we make to our image need to be made here. Outside AWS Fast Launch - there really isn’t much we can do to help with the Windows boot process, if you are able - you can uninstall Windows Defender which will massively improve start performance. Side note - I found in our use case we do not actually need Fast Launch as we do not actually need to run the OOBE process. We can set our culture using Set-Culture, etc. inside one of our components, and as long as we remove the sections in Unattend.xml related to OOBE, Windows will skip much of the setup process that EC2 Fast Launch deals with. When you start the output AMI, it will start as quickly as a Fast Launch AMI, but without the added expense of pre-provisioning EBS snapshots. The downside to this approach is that you won’t be able to configure Windows settings on the first boot, what you bake into the AMI is what you will start with - So make sure you set culture/timezone information correctly somewhere in one of your Image Builder components. For reference: So with all avenues to make Windows do less stuff on boot exhausted, there was only one choice left… Changes were made to the EKS Windows Bootstrapper code so it could be run as a Windows Service. The idea behind this is that we could squeeze a few more seconds out if we could run our code as Windows is starting services on boot instead of waiting for the userdata script to fire. This worked - however, it did break the AWS SSM Agent as a result as it also starts early. In the installation script included in the repo, we work around this by setting the SSM agent startup type to Automatic (Delayed). Faster Configure Network/Start K8s Services This basically involved translating the remainder of the code in the standard AWS bootstrapping scripts in EKS-StartupTask.ps1 Setup Container Network
        ... 
           [DllImport("vmcompute.dll")]
            static extern void HNSCall([MarshalAs(UnmanagedType.LPWStr)] string method,
                           [MarshalAs(UnmanagedType.LPWStr)] string path,
                           [MarshalAs(UnmanagedType.LPWStr)] string request,
                           [MarshalAs(UnmanagedType.LPWStr)] out string response);
            HNSCall("POST", "/networks", jsonString, out response);
        ...

https://github.com/atg-cloudops/eks-windows-bootstrapper/blob/8f519953209e3caea590652832acc74585ab1a45/BootstrapperService.cs#L514 Add routes to created NIC
        ...
          routeAddCommands.Append($"route ADD {ipAddrs[i]} MASK 255.255.255.255 0.0.0.0 IF {vNICIndex}");
        ...
        Process process = new Process();
        process.StartInfo.FileName = "cmd.exe";
        process.StartInfo.Arguments = $"/C {routeAddCommands}";
        process.StartInfo.RedirectStandardOutput = true;
        process.StartInfo.UseShellExecute = false;
        process.StartInfo.CreateNoWindow = true;
        process.Start();
        await process.WaitForExitAsync();

https://github.com/atg-cloudops/eks-windows-bootstrapper/blob/8f519953209e3caea590652832acc74585ab1a45/BootstrapperService.cs#L586


Start Kube-proxy and Kubelet in parallel once all configuration files have been written (all the previously converted code) Installation To install the bootstrapper, add this to a component in Image Builder: - name: InstallEksWindowsBootstrapper
        action: ExecutePowerShell
        inputs:
          commands:
            - |
              Invoke-WebRequest -Uri 'https://github.com/atg-cloudops/eks-windows-bootstrapper/releases/download/v1.29.1/Install-Service.ps1' -OutFile 'Install-Service.ps1'; 
              .\Install-Service.ps1; 
              Remove-Item 'Install-Service.ps1'; Putting everything together, I tested the output image using these settings: EC2 Instance

m4.xlarge (4 Core)
EBS


GP3 - 120GB/600Mbps/3600 IOPS Testing on these settings got me start times around 55s! We are finally under a minute, maybe spot instances are now viable for Windows EKS Nodes now that the 5-minute penalty is now 1 minute. Hold On… You Said A 30s Start Time! You Said as Fast as Linux! A 30s start time is possible! It just costs a lot. 😢 I ended up testing how fast the sum of all the software was by eliminating as many hardware bottlenecks as I could. Switched from GP3 → IO2 30K IOPS Switched from m4.xlarge → c6a.4xlarge Require Nitro Hypervisor It’s quite easy to change in Karpenter; simply change the Ec2NodeClass to change storage options, and then add the relevant keys in NodePool, e.g. blockDeviceMappings:
    - deviceName: /dev/sda1
      ebs:
        iops: 30000
        volumeSize: 120Gi
        volumeType: io2 - key: karpenter.k8s.aws/instance-hypervisor
          operator: In
          values:
            - 'nitro'
        - key: karpenter.k8s.aws/instance-cpu
          operator: In
          values:
            - '8' The beast that was produced by Karpenter was visible in K8s in 32s. It would be sub-30s with antivirus disabled. Our final tuning produces nodes in around 45s (Using GP3). You can tune for cost/performance yourself for your own scenario. Looking for Help EKS Windows bootstrapper is a simple app that writes config and starts Kubernetes services. It is currently set up for EKS 1.29. As Kubernetes goes through 1.30, 1.31, 1.32… it will need to be kept up to date… I am looking for help with this. 🙂 Previously… https://awstip.com/reducing-eks-windows-node-5-min-start-time-to-90s-eks-windows-bootstrapper-4314f72367a0?embedable=true https://awstip.com/reducing-eks-windows-node-5-min-start-time-to-90s-eks-windows-bootstrapper-4314f72367a0?embedable=true I threw in some tricks I used to make our Windows EKS nodes start in 90s rather than the 5 minutes a standard EKS Windows node takes. I introduced you to the git repo eks-windows-bootstrapper - the application replacing the AWS-provided configuration scripts for EKS Windows. https://github.com/atg-cloudops/eks-windows-bootstrapper?embedable=true https://github.com/atg-cloudops/eks-windows-bootstrapper?embedable=true In today’s story, I will walk you through how to make your Windows nodes take ~30s to start! Recap In the previous story, we got to the point where our start times looked like this: Let’s take a closer look at our latencies now: In order for us to get better launch times, we now have 2 areas where we can improve timing Windows Startup Windows Startup Configure Network/Start K8s Services Configure Network/Start K8s Services Improving Windows Startup Performance As we are using the AWS Image Builder ( https://aws.amazon.com/image-builder/ ) to build our custom AMIs as discussed in the previous story, any changes we make to our image need to be made here. Outside AWS Fast Launch - there really isn’t much we can do to help with the Windows boot process, if you are able - you can uninstall Windows Defender which will massively improve start performance. https://aws.amazon.com/image-builder/ Side note - I found in our use case we do not actually need Fast Launch as we do not actually need to run the OOBE process. We can set our culture using Set-Culture , etc. inside one of our components, and as long as we remove the sections in Unattend.xml related to OOBE, Windows will skip much of the setup process that EC2 Fast Launch deals with. When you start the output AMI, it will start as quickly as a Fast Launch AMI, but without the added expense of pre-provisioning EBS snapshots. Set-Culture Unattend.xml The downside to this approach is that you won’t be able to configure Windows settings on the first boot, what you bake into the AMI is what you will start with - So make sure you set culture/timezone information correctly somewhere in one of your Image Builder components. For reference: So with all avenues to make Windows do less stuff on boot exhausted, there was only one choice left… Changes were made to the EKS Windows Bootstrapper code so it could be run as a Windows Service. The idea behind this is that we could squeeze a few more seconds out if we could run our code as Windows is starting services on boot instead of waiting for the userdata script to fire. This worked - however, it did break the AWS SSM Agent as a result as it also starts early. In the installation script included in the repo, we work around this by setting the SSM agent startup type to Automatic (Delayed) . userdata Automatic (Delayed) Faster Configure Network/Start K8s Services This basically involved translating the remainder of the code in the standard AWS bootstrapping scripts in EKS-StartupTask.ps1 EKS-StartupTask.ps1 Setup Container Network
        ... 
           [DllImport("vmcompute.dll")]
            static extern void HNSCall([MarshalAs(UnmanagedType.LPWStr)] string method,
                           [MarshalAs(UnmanagedType.LPWStr)] string path,
                           [MarshalAs(UnmanagedType.LPWStr)] string request,
                           [MarshalAs(UnmanagedType.LPWStr)] out string response);
            HNSCall("POST", "/networks", jsonString, out response);
        ...

https://github.com/atg-cloudops/eks-windows-bootstrapper/blob/8f519953209e3caea590652832acc74585ab1a45/BootstrapperService.cs#L514 Setup Container Network ... 
           [DllImport("vmcompute.dll")]
            static extern void HNSCall([MarshalAs(UnmanagedType.LPWStr)] string method,
                           [MarshalAs(UnmanagedType.LPWStr)] string path,
                           [MarshalAs(UnmanagedType.LPWStr)] string request,
                           [MarshalAs(UnmanagedType.LPWStr)] out string response);
            HNSCall("POST", "/networks", jsonString, out response);
        ... https://github.com/atg-cloudops/eks-windows-bootstrapper/blob/8f519953209e3caea590652832acc74585ab1a45/BootstrapperService.cs#L514 Setup Container Network ... 
           [DllImport("vmcompute.dll")]
            static extern void HNSCall([MarshalAs(UnmanagedType.LPWStr)] string method,
                           [MarshalAs(UnmanagedType.LPWStr)] string path,
                           [MarshalAs(UnmanagedType.LPWStr)] string request,
                           [MarshalAs(UnmanagedType.LPWStr)] out string response);
            HNSCall("POST", "/networks", jsonString, out response);
        ... ... 
           [DllImport("vmcompute.dll")]
            static extern void HNSCall([MarshalAs(UnmanagedType.LPWStr)] string method,
                           [MarshalAs(UnmanagedType.LPWStr)] string path,
                           [MarshalAs(UnmanagedType.LPWStr)] string request,
                           [MarshalAs(UnmanagedType.LPWStr)] out string response);
            HNSCall("POST", "/networks", jsonString, out response);
        ... https://github.com/atg-cloudops/eks-windows-bootstrapper/blob/8f519953209e3caea590652832acc74585ab1a45/BootstrapperService.cs#L514 https://github.com/atg-cloudops/eks-windows-bootstrapper/blob/8f519953209e3caea590652832acc74585ab1a45/BootstrapperService.cs#L514 Add routes to created NIC
        ...
          routeAddCommands.Append($"route ADD {ipAddrs[i]} MASK 255.255.255.255 0.0.0.0 IF {vNICIndex}");
        ...
        Process process = new Process();
        process.StartInfo.FileName = "cmd.exe";
        process.StartInfo.Arguments = $"/C {routeAddCommands}";
        process.StartInfo.RedirectStandardOutput = true;
        process.StartInfo.UseShellExecute = false;
        process.StartInfo.CreateNoWindow = true;
        process.Start();
        await process.WaitForExitAsync();

https://github.com/atg-cloudops/eks-windows-bootstrapper/blob/8f519953209e3caea590652832acc74585ab1a45/BootstrapperService.cs#L586 Start Kube-proxy and Kubelet in parallel once all configuration files have been written (all the previously converted code) Add routes to created NIC ...
          routeAddCommands.Append($"route ADD {ipAddrs[i]} MASK 255.255.255.255 0.0.0.0 IF {vNICIndex}");
        ...
        Process process = new Process();
        process.StartInfo.FileName = "cmd.exe";
        process.StartInfo.Arguments = $"/C {routeAddCommands}";
        process.StartInfo.RedirectStandardOutput = true;
        process.StartInfo.UseShellExecute = false;
        process.StartInfo.CreateNoWindow = true;
        process.Start();
        await process.WaitForExitAsync(); https://github.com/atg-cloudops/eks-windows-bootstrapper/blob/8f519953209e3caea590652832acc74585ab1a45/BootstrapperService.cs#L586 Add routes to created NIC ...
          routeAddCommands.Append($"route ADD {ipAddrs[i]} MASK 255.255.255.255 0.0.0.0 IF {vNICIndex}");
        ...
        Process process = new Process();
        process.StartInfo.FileName = "cmd.exe";
        process.StartInfo.Arguments = $"/C {routeAddCommands}";
        process.StartInfo.RedirectStandardOutput = true;
        process.StartInfo.UseShellExecute = false;
        process.StartInfo.CreateNoWindow = true;
        process.Start();
        await process.WaitForExitAsync(); ...
          routeAddCommands.Append($"route ADD {ipAddrs[i]} MASK 255.255.255.255 0.0.0.0 IF {vNICIndex}");
        ...
        Process process = new Process();
        process.StartInfo.FileName = "cmd.exe";
        process.StartInfo.Arguments = $"/C {routeAddCommands}";
        process.StartInfo.RedirectStandardOutput = true;
        process.StartInfo.UseShellExecute = false;
        process.StartInfo.CreateNoWindow = true;
        process.Start();
        await process.WaitForExitAsync(); https://github.com/atg-cloudops/eks-windows-bootstrapper/blob/8f519953209e3caea590652832acc74585ab1a45/BootstrapperService.cs#L586 https://github.com/atg-cloudops/eks-windows-bootstrapper/blob/8f519953209e3caea590652832acc74585ab1a45/BootstrapperService.cs#L586 Start Kube-proxy and Kubelet in parallel once all configuration files have been written (all the previously converted code) Start Kube-proxy and Kubelet in parallel once all configuration files have been written (all the previously converted code) Installation To install the bootstrapper, add this to a component in Image Builder: - name: InstallEksWindowsBootstrapper
        action: ExecutePowerShell
        inputs:
          commands:
            - |
              Invoke-WebRequest -Uri 'https://github.com/atg-cloudops/eks-windows-bootstrapper/releases/download/v1.29.1/Install-Service.ps1' -OutFile 'Install-Service.ps1'; 
              .\Install-Service.ps1; 
              Remove-Item 'Install-Service.ps1'; - name: InstallEksWindowsBootstrapper
        action: ExecutePowerShell
        inputs:
          commands:
            - |
              Invoke-WebRequest -Uri 'https://github.com/atg-cloudops/eks-windows-bootstrapper/releases/download/v1.29.1/Install-Service.ps1' -OutFile 'Install-Service.ps1'; 
              .\Install-Service.ps1; 
              Remove-Item 'Install-Service.ps1'; Putting everything together, I tested the output image using these settings: EC2 Instance

m4.xlarge (4 Core)
EBS


GP3 - 120GB/600Mbps/3600 IOPS EC2 Instance m4.xlarge (4 Core)
EBS


GP3 - 120GB/600Mbps/3600 IOPS m4.xlarge (4 Core) EBS


GP3 - 120GB/600Mbps/3600 IOPS m4.xlarge (4 Core) EBS GP3 - 120GB/600Mbps/3600 IOPS GP3 - 120GB/600Mbps/3600 IOPS GP3 - 120GB/600Mbps/3600 IOPS GP3 - 120GB/600Mbps/3600 IOPS Testing on these settings got me start times around 55s! We are finally under a minute, maybe spot instances are now viable for Windows EKS Nodes now that the 5-minute penalty is now 1 minute. Hold On… You Said A 30s Start Time! You Said as Fast as Linux! A 30s start time is possible! It just costs a lot. 😢 I ended up testing how fast the sum of all the software was by eliminating as many hardware bottlenecks as I could. Switched from GP3 → IO2 30K IOPS Switched from m4.xlarge → c6a.4xlarge Require Nitro Hypervisor It’s quite easy to change in Karpenter; simply change the Ec2NodeClass to change storage options, and then add the relevant keys in NodePool, e.g. blockDeviceMappings:
    - deviceName: /dev/sda1
      ebs:
        iops: 30000
        volumeSize: 120Gi
        volumeType: io2 blockDeviceMappings:
    - deviceName: /dev/sda1
      ebs:
        iops: 30000
        volumeSize: 120Gi
        volumeType: io2 - key: karpenter.k8s.aws/instance-hypervisor
          operator: In
          values:
            - 'nitro'
        - key: karpenter.k8s.aws/instance-cpu
          operator: In
          values:
            - '8' - key: karpenter.k8s.aws/instance-hypervisor
          operator: In
          values:
            - 'nitro'
        - key: karpenter.k8s.aws/instance-cpu
          operator: In
          values:
            - '8' The beast that was produced by Karpenter was visible in K8s in 32s. It would be sub-30s with antivirus disabled. Our final tuning produces nodes in around 45s (Using GP3). You can tune for cost/performance yourself for your own scenario. Looking for Help EKS Windows bootstrapper is a simple app that writes config and starts Kubernetes services. It is currently set up for EKS 1.29. As Kubernetes goes through 1.30, 1.31, 1.32… it will need to be kept up to date… I am looking for help with this. 🙂

EKS Windows Node 30s Boot Now Possible - Start as Fast as Linux! (eks-windows-bootstrapper - Part 2)

You can see the hands-on video here: https://blog.sofianeouafir.com/docker/video-hands-on-introduction-to-docker-stack Introduction to Docker Stack Docker Stack is an essential tool for managing Docker services across multiple nodes in a Docker Swarm using a docker-compose.yml file. In this tutorial, I dive into Docker Stack’s deployment capabilities and the secure management of secrets, using a practical example involving Drupal and PostgreSQL. Docker-Compose File Setup Here’s our docker-compose.yml file that sets up the Drupal and PostgreSQL services: version: '3.8' services: drupal: image: drupal:8.2 ports: - "8080:80" deploy: replicas: 2 update_config: parallelism: 2 delay: 10s restart_policy: condition: on-failure postgres: image: postgres:14 secrets: - psql-pw environment: POSTGRES_PASSWORD_FILE: /run/secrets/psql-pw POSTGRES_DB: drupal POSTGRES_USER: user deploy: placement: constraints: [node.role == manager] secrets: psql-pw: external: true Understanding the Deploy Section The deploy section of the Docker Compose file specifies deployment strategies in a swarm environment, including: Replicas: Defines the number of instances for the service.
Update_config:
Parallelism: Sets how many service tasks are updated simultaneously.
Delay: Adds a delay between updates to different service tasks to ensure smooth roll-outs.
Restart_policy:
Condition: Determines under what conditions the service should be restarted. Managing Secrets in Docker Stack What is a Docker Secret? A Docker secret securely stores and manages sensitive data within Docker services, encrypted during transit and at rest, and only accessible by specifically authorized services. Managing Secrets with Docker Stack Secrets can be managed in Docker Stack in two ways: Using Secret Files: Ideal for development, storing sensitive data in local files securely transferred into Docker Swarm during deployment.
secrets: psql-pw: file: ./your-file.txt
External Secrets: For production, secrets are created directly in Docker using the CLI, avoiding the storage of sensitive information in files.
secrets: psql-pw: external: true Hands-On: Deploying the Stack in Docker Swarm To deploy your stack in Docker Swarm, follow these steps: Step 1: Prepare Your Docker Environment Ensure Docker is running and connected to your Docker Swarm. Refer to this guide for setting up a 3-node Docker Swarm. Step 2: Create and Edit the docker-compose.yml File On your swarm node, initialize and edit the docker-compose file to inclue our own docker-compose file: touch docker-compose.yml; vim docker-compose.yml; Step 3: Create the Secret echo "myverysecretpassword" | docker secret create psql-pw - Step 4: Deploy the Stack docker stack deploy -c docker-compose.yml demo-stack Step 5: Verify the Deployment List Services: docker stack services demo-stack
List Tasks: docker stack ps demo-stack Step 6: View the Secrets in the Container Get inside the container docker exec -it [container-name] bash See the secret values cat /run/secrets/psql-pw Step 7: View Logs and Debug docker service logs drupal
docker service logs postgres Step 8: Play with your configs For example, you can scale up and down your services by editing the replicas values in your docker-compose file and re-deploy using the same deploy command. Step 9: Play with your Drupal app! Your drupal application should now be up and running on port 8080! Conclusion You have successfully configured a robust Docker Swarm with three nodes. This setup is now running efficient instances of Drupal and PostgreSQL, demonstrating Docker Stack’s powerful capabilities for real-world applications. Happy deploying! You can see the hands-on video here: https://blog.sofianeouafir.com/docker/video-hands-on-introduction-to-docker-stack https://blog.sofianeouafir.com/docker/video-hands-on-introduction-to-docker-stack Introduction to Docker Stack Docker Stack is an essential tool for managing Docker services across multiple nodes in a Docker Swarm using a docker-compose.yml file . In this tutorial, I dive into Docker Stack’s deployment capabilities and the secure management of secrets, using a practical example involving Drupal and PostgreSQL. using a docker-compose.yml file Docker-Compose File Setup Here’s our docker-compose.yml file that sets up the Drupal and PostgreSQL services: docker-compose.yml version: '3.8' services: drupal: image: drupal:8.2 ports: - "8080:80" deploy: replicas: 2 update_config: parallelism: 2 delay: 10s restart_policy: condition: on-failure version: '3.8' services: drupal: image: drupal:8.2 ports: - "8080:80" deploy: replicas: 2 update_config: parallelism: 2 delay: 10s restart_policy: condition: on-failure postgres: image: postgres:14 secrets: - psql-pw environment: POSTGRES_PASSWORD_FILE: /run/secrets/psql-pw POSTGRES_DB: drupal POSTGRES_USER: user deploy: placement: constraints: [node.role == manager] postgres: image: postgres:14 secrets: - psql-pw environment: POSTGRES_PASSWORD_FILE: /run/secrets/psql-pw POSTGRES_DB: drupal POSTGRES_USER: user deploy: placement: constraints: [node.role == manager] secrets: psql-pw: external: true secrets: psql-pw: external: true Understanding the Deploy Section The deploy section of the Docker Compose file specifies deployment strategies in a swarm environment, including: deploy Replicas: Defines the number of instances for the service. Update_config: Parallelism: Sets how many service tasks are updated simultaneously. Delay: Adds a delay between updates to different service tasks to ensure smooth roll-outs. Restart_policy: Condition: Determines under what conditions the service should be restarted. Replicas : Defines the number of instances for the service. Replicas Update_config : Update_config Parallelism : Sets how many service tasks are updated simultaneously. Parallelism Delay : Adds a delay between updates to different service tasks to ensure smooth roll-outs. Delay Restart_policy : Restart_policy Condition : Determines under what conditions the service should be restarted. Condition Managing Secrets in Docker Stack What is a Docker Secret? A Docker secret securely stores and manages sensitive data within Docker services, encrypted during transit and at rest, and only accessible by specifically authorized services. Managing Secrets with Docker Stack Secrets can be managed in Docker Stack in two ways: Using Secret Files: Ideal for development, storing sensitive data in local files securely transferred into Docker Swarm during deployment. secrets: psql-pw: file: ./your-file.txt External Secrets: For production, secrets are created directly in Docker using the CLI, avoiding the storage of sensitive information in files. secrets: psql-pw: external: true Using Secret Files : Ideal for development, storing sensitive data in local files securely transferred into Docker Swarm during deployment. Using Secret Files secrets: psql-pw: file: ./your-file.txt External Secrets : For production, secrets are created directly in Docker using the CLI, avoiding the storage of sensitive information in files. External Secrets secrets: psql-pw: external: true Hands-On: Deploying the Stack in Docker Swarm To deploy your stack in Docker Swarm, follow these steps: Step 1: Prepare Your Docker Environment Ensure Docker is running and connected to your Docker Swarm. Refer to this guide for setting up a 3-node Docker Swarm. this guide Step 2: Create and Edit the docker-compose.yml File On your swarm node, initialize and edit the docker-compose file to inclue our own docker-compose file: touch docker-compose.yml; vim docker-compose.yml; Step 3: Create the Secret echo "myverysecretpassword" | docker secret create psql-pw - Step 4: Deploy the Stack docker stack deploy -c docker-compose.yml demo-stack Step 5: Verify the Deployment List Services: docker stack services demo-stack List Tasks: docker stack ps demo-stack List Services : docker stack services demo-stack List Services docker stack services demo-stack List Tasks : docker stack ps demo-stack List Tasks docker stack ps demo-stack Step 6: View the Secrets in the Container Get inside the container docker exec -it [container-name] bash See the secret values cat /run/secrets/psql-pw Step 7: View Logs and Debug docker service logs drupal
docker service logs postgres Step 8: Play with your configs For example, you can scale up and down your services by editing the replicas values in your docker-compose file and re-deploy using the same deploy command. Step 9: Play with your Drupal app! Your drupal application should now be up and running on port 8080! Conclusion You have successfully configured a robust Docker Swarm with three nodes. This setup is now running efficient instances of Drupal and PostgreSQL, demonstrating Docker Stack’s powerful capabilities for real-world applications. Happy deploying!

An Introduction to Docker Stack: Deployment and Secrets Management

Recommendations by Concise User Profiles from Review Text: Ethics Statement and References

deployments come in all shapes and sizes. We support bare metal installs on any version of , containerized installs on any version of (including Red Hat OpenShift), and installs just about anywhere you can deploy a small lightweight single binary. But with flexibility comes the inevitability that edge case issues will require debugging. MinIO Linux Kubernetes In this blog post, we’ll show you how to debug a MinIO install running in Kubernetes and also some of the common issues you might encounter when doing bare metal installation and how to rectify them. Kubernetes Debugger Pod There are a few ways to access the MinIO API running inside a Kubernetes cluster. We can use or set up a listening on to be able to access the API. Both of these methods offer a way to access the service from outside the network, but they do come with one major downside: You can only access the Service that the NodePort or Port Forwarding references on an available port (not the usual configuration for the application). For example, you have to access the MinIO API, usually found on port , via a randomly assigned port. kubectl port-forwarding Service NodePort 9000 3xxxx What if I told you there was a better way – and it's not novel? When debugging applications you want to have full access to the native run-time environment so you can use various tools to troubleshoot and debug the cluster. One way to do that is launching a “busybox” style pod and installing all the required tools needed to debug the application. First launch a into the same namespace as your MinIO install. In order to do this create a yaml file called with the following yaml. Pod debugger-pod.yaml apiVersion: v1

kind: Pod

metadata:

  name: mc

  labels:

    app: mc

spec:

  containers:

  - image: minio/mc:latest

    command:

      - "sleep"

      - "604800"

    imagePullPolicy: IfNotPresent

    name: mc

  restartPolicy: Always The above Pod configuration is pulling the image for MinIO utility. In order to ensure the pod doesn’t just launch and then exit, we’ve added a command. mc sleep Once the yaml is saved apply the configuration to the Kubernetes namespace where the MinIO cluster is running kubectl apply -f debugger-pod.yaml Once the pod is up and running access it via shell $ kubectl exec -i -t -n default mc -c mc -- sh -c "(bash || ash || sh)"

[root@mc /]# Then with you can access the MinIO cluster mc [root@mc /]# mc alias set myminio    --insecure

Added `myminio` successfully. Now that we have a debugger pod up and running, you can perform action on the cluster directly within the same network. For example, if the replication was broken due to an site going offline or a hardware failure, you can resync any pending objects to be replicated using the following command [root@mc /]# mc admin replicate resync start minio1 minio2


[root@mc /]# mc admin replicate resync status minio1 minio2


✔ ✔ ✔

ResyncID: 		 2248d1d1-633f-4d61-b938-d8ea0b9b2d31

Status:   		 Completed

Objects:  		 2225

Versions: 		 2225

FailedObjects:     0

Throughput:   	 5.3 MiB/s

IOPs:     		 124.23 objs/s

Transferred:  	 94 MiB

Elapsed:  		 17.909833202s

CurrObjName:  	 testbucket/web-app/tsconfig.json Another reason you would run the debugger pod is if there are some file system permissions or invalid groups configurations in your pod, you can update them using the debugger pod [root@mc /]# chgrp -R 1000780050 .minio.sys/ The above debugging method can also be used in bare metal environments. For instance you can launch a busybox or bastion node with installed and follow the same instructions as above. mc Debugging Bare Metal Bare metal Linux installs are the most straightforward. In fact it just takes a few commands to get MinIO installed and running with SystemD. For details, please see . Configuring MinIO with SystemD Once in a great while, bare metal installs go awry. Here are some of the (not-so-common) pitfalls that we are asked about  in or . These pitfalls are not hardware or operating specific but can be useful to know in any kind of environment. SUBNET Slack File Permission One of the most common pitfalls is the file permissions of the MinIO binary and the configuration file. If this occurs, when you start MinIO using SystemD you will see and here is the full stack trace Assertion failed for MinIO. # systemctl status minio.service

● minio.service - MinIO

     Loaded: loaded (/etc/systemd/system/minio.service; enabled; vendor preset: enabled)

     Active: inactive (dead)

     Assert: start assertion failed at Tue 2023-12-26 18:21:38 PST; 8s ago

             AssertFileIsExecutable=/usr/local/bin/minio was not met

       Docs: https://docs.min.io


Dec 26 18:13:37 minio1 systemd[1]: minio.service: Starting requested but asserts failed.

Dec 26 18:17:50 minio1 systemd[1]: Assertion failed for MinIO.

Dec 26 18:21:38 minio1 systemd[1]: minio.service: Starting requested but asserts failed.

Dec 26 18:21:38 minio1 systemd[1]: Assertion failed for MinIO. This could be caused by a number of reasons, let's go down the list and check for each of them. : The binary, in this example located at needs to have permission for user and group, respectively. MinIO Binary /usr/local/bin/minio root:root # ll /usr/local/bin/minio

total 93804

-rwxr-xr-x 1 root    root    96018432 Nov 15 16:35  minio* : The MinIO service needs to run under a unique Linux user and group for security purposes, never run as a user. By default we use for the user and group names. In the SystemD service config file you should see something like this MinIO Service User and Group root minio-user User=minio-user

Group=minio-user : The directory where MinIO data will be stored needs to be owned by or whichever user you decide to run the MinIO service as above. MinIO Data Dir minio-user:minio-user # ls -l /mnt

total 4

drwxrwxr-x 2 minio-user minio-user 4096 Dec 27 09:58 data : Both the config files should have permissions for user and group like so SystemD and MinIO config root:root # ls -l /etc/default/minio

-rw-r--r-- 1 root root 1330 Dec 27 09:52 /etc/default/minio


# ls -l /etc/systemd/system/minio.service

-rw-r--r-- 1 root root 941 Dec 26 17:13 /etc/systemd/system/minio.service : The entire install process should be run as . You can also try if your user has permissions but the recommendation is to run as root as the install needs to place files in a bunch of places that only the user can access. Your bash prompt should have a and not a like so Run as Root root sudo root # $ vs # $ If none of the above work, the best approach is to remove the app, directories and configs and start a fresh install as a root user. Port conflict Another common issue related to deleted files which still hold on to the process, which causes port conflicts. Even when a service is not running, you may be unable to start a new service on the existing port or the service that is running will misbehave (such as not allowing you to login). # lsof -n | grep (deleted)

COMMAND PID USER FD TYPE DEVICE   SIZE 	NODE NAME

nginx   	13423 root 5u  	REG 253,3   42949672960 	17 (deleted)

minio 	13423 minio 6u    REG 253,3 	0         	      18 (deleted)

minio       13423 minio 7u    REG 253,3 	0         	      19 (deleted) You might see errors such as those below on a MinIO install Login Failed net::ERR_FAILED 500 Internal Server Error 401 Unauthorized The screenshot above shows an internal server error and an unauthorized error. While looking at the surface it looks unclear what has caused this error, we can debug with a little linux knowledge what to look for that could cause this, let's take a gander. There are several ways to debug this issue, first lets check to see if multiple MinIO processes are running on the same node # ps aux | grep -i minio

minio-u+    5048  0.3  1.7 1594008 144384 ?      Ssl  11:03   0:01 /usr/local/bin/minio server --console-address :9001 /mnt/data/disk1/minio


minio-u+    9276  0.3  1.7 1594208 144301 ?      Ssl  11:25   0:01 /usr/local/bin/minio server --console-address :9001 /mnt/data/disk1/minio As we can see above there are 2 MinIO processes running. Start by killing the process that is older or has been running the longest, in this case it seems to be the process ID . 5048 kill -9 5048 Sometimes even after killing the process the service might still not start or might still get hung up because it has reserved a process number but not let it go. This can be caused by files that have been deleted but are still being tracked by the operating system. You can find the deleted files via LSOF lsof -n | grep '(deleted)' Last but not least, if there are no deleted files left over or hung processes and if everything looks absolutely clean, the last resort is to quickly restart the node. This is a no-nonsense method that  shuts down and clears any pending files and processes so you start a fresh install. SUBNET to the rescue Although rare, installation edge cases will always exist. MinIO customers know that they have nothing to worry about because they can quickly message our engineers – who have written the code – via the portal. We've seen almost everything under the sun, so while the issue might look cryptic or mind boggling at first glance, we'll put our years of expertise debugging installations in many varied environments to work and help you in a jiffy. SUBNET If you have any questions on troubleshooting and debugging installs be sure to reach out to us on ! MinIO Slack

Pro Tips for Debugging MinIO: Overcoming Common Issues in Kubernetes and Bare Metal Environments

MinIO ডিবাগ করার জন্য প্রো টিপস: কুবারনেটস এবং বেয়ার মেটাল পরিবেশে সাধারণ সমস্যাগুলি অতিক্রম করা

Profi-Tipps zum Debuggen von MinIO: Überwindung häufiger Probleme in Kubernetes- und Bare-Metal-Umgebungen

Consejos profesionales para depurar MinIO: superar problemas comunes en Kubernetes y entornos bare metal

Conseils de pro pour déboguer MinIO : surmonter les problèmes courants dans les environnements Kubernetes et Bare Metal

मिनियो डिबगिंग के लिए प्रो टिप्स: कुबेरनेट्स और बेयर मेटल वातावरण में आम समस्याओं पर काबू पाना

MinIO デバッグのプロのヒント: Kubernetes とベアメタル環境での一般的な問題の克服

MinIO 디버깅을 위한 전문가 팁: Kubernetes 및 베어메탈 환경의 일반적인 문제 극복

Dicas profissionais para depuração do MinIO: superando problemas comuns em ambientes Kubernetes e Bare Metal

Советы для профессионалов по отладке MinIO: решение распространенных проблем в Kubernetes и средах с голым железом

MinIO'da Hata Ayıklamaya Yönelik Profesyonel İpuçları: Kubernetes ve Bare Metal Ortamlarında Yaygın Sorunların Aşılması

Mẹo chuyên nghiệp để gỡ lỗi MinIO: Khắc phục các sự cố thường gặp trong môi trường Kubernetes và Bare Metal

调试 MinIO 的专业技巧：解决 Kubernetes 和裸机环境中的常见问题

Hello again! Today, I'd like to explore a topic that you may not have come across if you don't have a background in computer science or an affinity towards static analysis. We are going to dive into the world of ASTs, and once we have a firm grasp of the topic, apply our knowledge to building a custom ESLint rule. As far as prerequisite knowledge goes for this article, I would like readers to be familiar with JavaScript and, specifically, have some experience with ESLint. I'll try my best to define everything as we go, and if that isn't enough, I'll link some resources to hopefully clear things up. With that, let's get started. Getting Started with ASTs First off... what is an AST? ASTs or bstract yntax rees are tree representations of code. The nodes of the tree are organized in such a way that the children of any given node are from that of its parent node. There are two fundamental processes that go into building an AST: tokenization and parsing. A S T smaller syntactic units Tokenization is concerned with taking a stream of characters as input and outputs a linear list of tokens. Once tokens are created, they need to be transformed into a hierarchical tree that defines the grammatical structure of the tokens, which is known as parsing. We said a lot just then... how're you doing? Let's use an example to illustrate this definition. I find it best to learn by doing so. Let's get a visual for these bstract yntax rees that we're talking about. Navigate over to in a new browser tab so we can paste our own code and inspect the corresponding AST. You should see something like the following: A S T astexplorer.net At the top of the website, you should see some configuration options. In my screenshot, "JavaScript" is the programming language we will be using in our code snippet. We'll place our example code on the left-hand side of the screen below the toolbar. The next item, "babel-eslint9," is the parser option I've selected, and this will help us build the AST that we are concerned with. Don't worry about the other options available in the toolbar. Finally, on the right side of the screen, you'll see "Tree" highlighted, followed by some text. In my screenshot, we see "Program" followed by an object with some properties. This is the AST for our empty program! Let's add some code to continue reasoning through ASTs. Add the following code snippet into the text area on the left side of the site (below the toolbar): function bar() {
  const a = 1;
  console.log(2 + a);
} Now that we have some code added to our AST Explorer editor, do you notice anything different about the tree view on the right-hand side? The body has changed and has a FunctionDeclaration entry! This FunctionDeclaration corresponds to the snippet we added, the function . Let's continue to inspect the AST for another level. Before we expand, can you guess what might be contained at the next level? Look at our code snippet for a hint! bar Did you guess right? I know I didn't when I first started learning about ASTs 😅. But let's revisit our understanding of ASTs. In the beginning, we mentioned that "nodes of the tree are organized in such a way where the children of any given node are Does this definition make more sense now after this example? We can see that we have the following hierarchy of syntactic units so far: smaller syntactic units." Program - the root of our code FunctionDeclaration - function bar() BlockStatement - the body of our function e.g., what is contained within ... more AST nodes as they relate to the rest of our program You can see from the hierarchy above that each node of our tree is a than that of its parent. If we continued down the tree, our result would be: smaller syntactic unit Program - the root of our code FunctionDeclaration - function bar() BlockStatement - the body of our function e.g., what is contained within VariableDeclaration - const a = 1; VariableDeclarator - a ExpressionStatement - console.log(a + 1) CallExpression - log(a + 1); Nice work! Hopefully, you now have a grasp of what an AST is and how our code might be translated into an AST. But let's push further. ESLint is one of the most popular static code analysis tools for identifying issues with JavaScript code. Chances are, if you worked with a production-grade JavaScript codebase, you have probably worked with ESLint. We can apply our knowledge of ASTs to write our own custom ESLint rule. ASTs in Action With ESLint ESLint, as you may know, is a configurable JavaScript linter. ESLint helps us catch problematic patterns of JavaScript code as well as coaches us toward the style guidelines of a particular project. At the core, are the most foundational piece of the system. You can think of ESLint rules as a type of lint, and we can define our own custom rules to define the patterns and styles we care about in our JavaScript code. When writing a custom rule, we use ESLint's built-in visitor methods to inspect the AST of JavaScript code and flag whatever problematic code we want. For the purposes of this exercise, let's say we want to create a custom rule that flags any constant variable declaration that has a non-uppercase name. For example, we would flag "const ABC = 1;" but not "const ABC = 1;". ESLint rules Now that we have the problem scoped, can you think of which AST nodes we would want to look for, given this type of lint we are trying to achieve? We know we are concerned with variable declaration statements, so that would be a great place to start. Let's get our project set up. First, let's set up a new project by running these commands in your terminal of choice: mkdir custom-eslint-rule
cd custom-eslint-rule
npm init -y
npm install --save-dev eslint
touch all-uppercase-const-declarations.js
touch all-uppercase-const-declarations.test.js What we're doing above is creating a new project with NPM as our package manager. We are also creating one file to house our custom lint's logic and another to test the logic. Next, let's stub out all-uppercase-const-declarations.js with the template of a custom rule. Make sure it has the following contents: module.exports = {
  meta: {},
  create(context) {
    return {};
  },
}; Great! Now, we have a module that has two important properties. The first is the meta property. Meta refers to the metadata associated with the rule that we are creating, and you can find more specifics about that . The next is the create property. This is where all of our custom rule logic will be housed. Notice the context object, which is the input parameter to the create function. The context object has properties like the id of the rule, the filename being visited, the current working directory, and much more. But for the purposes of this article, we'll skip over the other details. Let's add some more code to all-uppercase-const-declarations.js: here module.exports = {
  meta: {
    type: "problem",
    docs: {
      description:
        "A rule that enforces all constant variable declaration names be uppercase.",
    },
  },

  create(context) {
    return {
      VariableDeclarator(node) {},
    };
  },
}; Now we've added some documentation to our lint so when violations do occur, developers are aware of why the code was flagged. We've also added a VariableDeclarator method. But what does that mean? Essentially, when the AST is built, lint rules are run against the AST to flag problematic patterns. The visitor methods provided by ESLint allow us to access the AST and inspect the underlying code to do our analysis. Let's finish up our custom rule in all-uppercase-const-declarations.js: visitor module.exports = {
  meta: {
    type: "problem",
    docs: {
      description:
        "A rule that enforces all constant variable declaration names be uppercase.",
    },
  },

  create(context) {
    return {
      VariableDeclarator(node) {
        const parentNode = node.parent;
        const nodeName = node.id.name;
        if (
          parentNode.kind === "const" &&
          nodeName !== nodeName.toUpperCase()
        ) {
          context.report({
            node,
            message: "All constant variable declarations must be uppercase.",
          });
        }
      },
    };
  },
}; Now, we've filled out the rest of all-uppercase-const-declarations.js. We are looking at the parent of the VariableDeclarator, which we know from our exercise above with ASTs is the VariableDeclaration, and checking if the declaration is of constant type. Next, we look at the node name from the identifier of the declarator node and compare that to its uppercase version. If the declaration name isn't all uppercase, we use the context report method to report the error. But now, let's test out our lint! Open up all-uppercase-const-declarations.test.js and ensure the contents look like: const { RuleTester } = require("eslint");

const rule = require("./all-uppercase-const-declarations");

const ruleTester = new RuleTester({ parserOptions: { ecmaVersion: 2015 } });

ruleTester.run("all-uppercase-const-declarations", rule, {
  valid: [{ code: "const ABC = 1;" }],
  invalid: [{ code: "const abc = 1;", errors: 1 }],
});

console.log("If we made it this far our test passed!"); We are using the RuleTester helper that ESLint provides and using the run method that supports inputting our own valid and invalid test cases. We do this by defining object entries keyed by the property name code and valued by a string representation of the code we want to test. As you can see, we are testing the happy path of a valid test case with our variable in uppercase format. But, in the invalid case, we have all lowercase for the variable name. We indicate to the RuleTester that there should be one error by providing the errors key followed by the number of expected errors. Finally, we add a console statement at the end of our code block that will show if RuleTester doesn't throw as the result of a lint error. Let's give this a try by running: "node all-uppercase-const-declarations.test.js" in your terminal window. That passed! Now, let's update the invalid test case entry to be all uppercase and leave everything else as is. Run the test again. You should see a thrown assertion error like "AssertionError [ERR_ASSERTION]: Should have one error but had 0: []". That is because our invalid test case is now a valid one. Feel free to mess around with the test cases to iron out our code! Well, that is all I have today! Definitely check out the ESLint documentation for more information, but hopefully, you left learning something new today. Static analysis is a really interesting and important topic for developer productivity. Who knows, maybe you'll write a letter for your workplace sometime in the near future! Cheers!

Usings ASTs and Crafting Custom ESLint Rules for JavaScript Development

How to Master Authentication and User Flow in Node.js With Knex and Redis

Knex এবং Redis দিয়ে Node.js-এ প্রমাণীকরণ এবং ব্যবহারকারীর প্রবাহ কীভাবে আয়ত্ত করা যায়

So meistern Sie die Authentifizierung und den Benutzerfluss in Node.js mit Knex und Redis

Cómo dominar la autenticación y el flujo de usuarios en Node.js con Knex y Redis

Comment maîtriser l'authentification et le flux d'utilisateurs dans Node.js avec Knex et Redis

Knex और Redis के साथ Node.js में प्रमाणीकरण और उपयोगकर्ता प्रवाह में कैसे महारत हासिल करें

Knex と Redis を使用して Node.js で認証とユーザー フローをマスターする方法

Knex 및 Redis를 사용하여 Node.js에서 인증 및 사용자 흐름을 마스터하는 방법

Como dominar a autenticação e o fluxo do usuário em Node.js com Knex e Redis

Как освоить аутентификацию и поток пользователей в Node.js с помощью Knex и Redis

Knex ve Redis ile Node.js'de Kimlik Doğrulama ve Kullanıcı Akışında Ustalaşma

Cách làm chủ xác thực và luồng người dùng trong Node.js với Knex và Redis

如何使用 Knex 和 Redis 在 Node.js 中掌握身份验证和用户流程

LONDON, United Kingdom, March 13th, 2024/Chainwire/-- Bitcoin Dogs has now raised a spectacular total of $10.6 million as it nears the final 48 hours of its presale, after which the 0DOG tokens will become available for public trading. The ICO, the first-ever for a token built on the Bitcoin blockchain, began on the 14th of February. It debuted with a that garnered thousands of views and achieved viral growth, amassing a community of over on X and in excess of 25k members on , all in under 30 days. product video 110k followers Telegram The exceptional response has been powered significantly by Bitcoin Dogs' innovative use of the Bitcoin ordinals protocol, a 2023 update to Bitcoin that enables token minting and NFTs on the Bitcoin blockchain. This places Bitcoin Dogs firmly within a range of Web3 camps since the project offers both its 0DOG token, an NFT collection, and a GameFi experience to those who invest. 0DOG is currently available to purchase at its final stage price of $0.0404 before it becomes available for public trading. The presale will end on Friday 15th March. 0DOG is available to buy on the . Bitcoin Dogs website Born And Bred On Bitcoin Ordinals allow collectibles and custom tokens to be written onto satoshis, or “sats” — the smallest denomination of a bitcoin. This has allowed NFTs and “BRC-20” tokens to flourish on the Bitcoin network, and according to , Bitcoin is now jostling for the title of dominant NFT chain over Ethereum. Grayscale Bitcoin Dogs uses Ordinals in two ways, making it a potential flagship project for the protocol. Firstly, the 0DOG token is issued under the BRC-20 standard, meaning that 0DOG tokens are stored and transferred over the Bitcoin network, much like ERC-20 tokens like SHIB on Ethereum. BRC-20 tokens have been extremely popular since they debuted last year, and two remain in the cryptocurrencies by market cap. Second, available only to 0DOG holders, Bitcoin Dogs will mint 10,000 NFTs on the Bitcoin blockchain, using Ordinals to inscribe images on satoshis. top 100 Ordinals NFT collections like and NodeMonkes have become popular in recent months, with the latter hitting in early March. employs the same 8-bit graphic style as these projects while implementing the ever-popular “doge” style imagery on top of this. Bitcoin Frogs $1 million in sales Bitcoin Dogs The Bitcoin Dogs team is optimistic that the use cases for Ordinals position Bitcoin Dogs to benefit from the general bullish sentiment surrounding the Ordinals protocol. The team is hoping that owners will replicate the success stories of ORDI and other notable NFT collections. The Presale As it nears its final 48 hours, 0DOG is currently on sale for $0.0404, the final fixed price before the token becomes available for public trading. At the end of the presale, any unsold tokens will be burned, permanently removing them from circulation. This means that the total supply, originally 900 million 0DOG, will ultimately be decided by the market. A burn would reduce the supply, which could, in theory, drive up the price of 0DOG if demand were to persist. like this have been credited with creating long-term value in tokens like Bitcoin and numerous other cryptocurrencies. Deflationary pressures The Bitcoin halving, scheduled for April and traditionally associated with increased scarcity, is anticipated by the team to potentially boost Bitcoin prices beyond the $72.968k all-time high. Furthermore, the team expects this surge to ripple out into the wider crypto markets, suggesting that the broader crypto market could stand to benefit from the ensuing hype. The presale will end on Friday 15th March. About Bitcoin Dogs Bitcoin Dogs is breaking new ground in the Bitcoin ecosystem. For the first time ever, NFTs, gaming, and new token types come together to offer the first ICO on the original Bitcoin blockchain. The truly permissionless immutability of Bitcoin is being harnessed to create the 0DOG token, while a play-to-earn (P2E) gaming experience and NFT collection are being developed exclusively for 0DOG holders. For more information about Bitcoin Dogs (0DOG), users can visit the . website | | Official Website Whitepaper Socials Contact Bitcoin Dogs Team Bitcoin Dogs marketing@bitcoindogs.club This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here.

World's First ICO On Bitcoin Blockchain Nears Final 48 Hours

Often, when we build enterprise software solutions meant for independent deployment across different customer environments, we leverage a central image repository. This repository is exposed to the enterprise, who then installs it in their environment. These applications may require variables or files specific to the client's environment, which need to be injected into the image for it to run. As it's impractical to have a separate image for each customer, we use a single image that is customized and injected with required files or variables during deployment. This blog explores how to create a standardized image, inject necessary variables in the form of a file, and deploy it on a cluster. For this we will create a python app, dockerize it, build it and push it to a repository. Once pushed we will be creating standard k8 manifests and Helm charts where we will be injecting our file/variables into it. Kubernetes Application and Image Creation Let's create a simple Python program which retrieves the variables "DB_HOST" and "DB_PASSWORD", then uses them to print both of these variables to the console. import os
from dotenv import load_dotenv

# Load environment variables from .env file
load_dotenv()

db_host = os.getenv("DB_HOST")
db_password = os.getenv("DB_PASSWORD")

print(db_host)
print(db_password) Next, we'll create a Docker image that packages our application using python:3.9-slim and adds all the required packages to the image. The entry point for the image is the above Python file named . Once completed, we'll push our image to an image repository such as ECR or Docker Hub. main.py # Use an official Python runtime as the base image
FROM python:3.9-slim

# Set the working directory in the container
WORKDIR /app

# Copy the current directory contents into the container at /app
COPY . /app

# Install any needed dependencies
RUN pip install --no-cache-dir python-dotenv

# Run the Python script when the container launches
CMD ["python", "main.py"] Creating Deployment Files Once we have the image ready in our preferred image repository, we need to deploy these images on a server. Nowadays, most deployments have moved to Kubernetes, so we'll use it as our deployment platform. Deployment in Kubernetes can be achieved by creating Kubernetes manifests directly or creating HELM charts (or Kustomize), which act like package managers to deploy applications. Let's explore both options: Creating standard manifest files Below, we're creating a deployment of one replica, a service of type NodePort to expose the application, and a secret object that takes the content of our .env file and injects it into the pod when we deploy the application. apiVersion: apps/v1
kind: Deployment
metadata:
  name: python-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: python-app
  template:
    metadata:
      labels:
        app: python-app
    spec:
      containers:
      - name: your-container-name
        image: your-image-name:your-image-tag
        ports:
        - containerPort: 80
        volumeMounts:
        - name: env-volume
          mountPath: /app/.env
          subPath: .env
      volumes:
      - name: env-volume
        secret:
          secretName: python-app-env-secret
---

apiVersion: v1
kind: Service
metadata:
  name: python-app-service
spec:
  selector:
    app: python-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30001
  type: NodePort

---

apiVersion: v1
kind: Secret
metadata:
  name: python-app-env-secret
type: Opaque
data:
  .env: |
    DB_HOST=test
    DB_PASSWORD=password Creating HELM chart To create a helm chart, simply run . For our project here, we'll run . This should create a Python-app folder, which contains the standard HELM template that can be modified according to our requirements. The generated folder should have the following folder/file structure: helm create <app-name> helm create python-app my-chart/
├── charts/
├── templates/
│   ├── deployment.yaml
│   ├── hpa.yaml
│   ├── ingress.yaml
│   ├── NOTES.txt
│   ├── service.yaml
│   └── serviceaccount.yaml
│   ├── hpa.yaml
│   ├── _helpers.tpl
├── values.yaml
└── Chart.yaml We need to create a configmap.yaml file in the templates folder and add the following content to it: # templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  .env: |
    DB_HOST={{ .Values.env.DB_HOST }}
    DB_PASSWORD={{ .Values.env.DB_PASSWORD }} The deployments.yaml should look something like this: # templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "python-app.name" . }}
  labels:
    app: {{ include "python-app.name" . }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ include "python-app.name" . }}
  template:
    metadata:
      labels:
        app: {{ include "python-app.name" . }}
    spec:
      containers:
      - name: {{ .Chart.Name }}
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        ports:
        - containerPort: 80
        volumeMounts:
        - name: cm-volume
          mountPath: /app/.env
          subPath: .env
      volumes:
      - name: cm-volume
        configMap:
          name: {{ include "python-app.name" . }} The service.yaml: # templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: {{ include "python-app.name" . }}
spec:
  selector:
    app: {{ include "python-app.name" . }}
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30001
  type: NodePort The _helpers.tpl should have the following content: # templates/_helpers.tpl.yaml
{{- define "python-app.fullname" -}}
{{- printf "%s-%s" .Release.Name .Chart.Name }}
{{- end }}{{- define "python-app.name" -}}
{{- printf "%s" .Chart.Name }}
{{- end }} In values.yaml, pass your secrets and image repository and tag: # values.yaml
image:
  repository: krishnadutt/my-python-app
  tag: latest
replicaCount: 1
env:
  DB_HOST: test
  DB_PASSWORD: your_database_password For this project, delete the rest of the files in the templates folder. Once done, apply all the manifest files or simply add the helm repository and install it in your k8s. Once deployed, if we execute into the image in Kubernetes, we should see the file and if we search the logs, we should find that .env values are used and those values are printed out by the program. Like my content? Feel free to reach out to my for interesting content and productive discussions. LinkedIn

Enhancing Dockerized Application Deployment: File Passing Strategies with Helm Charts

How to Build a Digital Collectibles Portal Using Flow and Cadence (Part 1)

ফ্লো এবং ক্যাডেন্স ব্যবহার করে কীভাবে একটি ডিজিটাল সংগ্রহযোগ্য পোর্টাল তৈরি করবেন (পর্ব 1)

So erstellen Sie ein digitales Sammlerportal mit Flow und Cadence (Teil 1)

Cómo crear un portal de coleccionables digitales utilizando flujo y cadencia (Parte 1)

Comment créer un portail d'objets de collection numériques à l'aide de Flow et de Cadence (Partie 1)

प्रवाह और ताल का उपयोग करके डिजिटल संग्रहणीय पोर्टल कैसे बनाएं (भाग 1)

フローとケイデンスを使用してデジタル グッズ ポータルを構築する方法 (パート 1)

Flow와 Cadence를 사용하여 디지털 수집품 포털을 구축하는 방법(1부)

Como construir um portal de colecionáveis digitais usando fluxo e cadência (parte 1)

Как создать портал цифровых предметов коллекционирования, используя поток и ритм (часть 1)

Akış ve Ritim Kullanarak Dijital Koleksiyon Portalı Nasıl Oluşturulur (Bölüm 1)

Cách xây dựng cổng sưu tầm kỹ thuật số bằng cách sử dụng Flow và Cadence (Phần 1)

如何使用 Flow 和 Cadence 构建数字收藏品门户（第 1 部分）

Overview Helm is the package manager for Kubernetes, like apt, yum, or Homebrew for traditional operating systems. It simplifies the deployment and management of applications on Kubernetes clusters by packaging all necessary components into a single, manageable unit. Why Helm? : Helm packages, known as charts, bundle together all the Kubernetes manifests (like deployments, services, etc.) needed to deploy an application, making the deployment process straightforward and repeatable. Simplifies Kubernetes Deployments : Helm charts can include other charts, allowing complex applications to manage their dependencies effectively. Manages Dependencies : Helm tracks versions of deployments, enabling rollbacks to previous states if needed. Version Control for Deployments What Is It Made of? : A Helm chart is a bundle containing all information necessary to create an instance of a Kubernetes application. It includes resource definitions and configuration files. Chart : The configuration contains customizable parameters that merge with a chart to create a release. These parameters allow the same chart to be used in different environments or configurations. Config : A release is an instance of a chart running in a Kubernetes cluster combined with a specific configuration. Release Helm Architecture Diagram : Helm Client : Local chart development and managing repositories. Chart Development : Manages releases/repos and requests chart installation or release upgrade/uninstallation through Helm Library. Release Management : Helm Library : Handles combining charts and configurations to create releases and installing/upgrading/uninstalling charts. Chart Management : Interfaces with the Kubernetes API server. Interacts with Kubernetes Creating a Chart Creating a Helm chart involves setting up a predefined directory structure with at least two files: for metadata about the chart and for default configuration values. Chart.yaml values.yaml : A basic chart directory will have the following layout: Structure : Contains metadata about the chart such as name, version, and description. Chart.yaml : Specifies default configuration values for the chart. values.yaml : This directory contains template files that generate Kubernetes manifest files based on the values provided. templates/ : Helm uses a templating engine to substitute values in the chart templates, creating Kubernetes manifests tailored to specific deployments. This allows for dynamic adjustment of resources, labels, and configurations without altering the original chart files. Templating Practice : Scenario A startup, "DevOps Solutions" adopts Helm to streamline their Kubernetes deployments. You're a consultant tasked with creating a basic Helm Chart for . It should be customizable for different environments using values. n8n Clone the repo. git clone https://github.com/perplexedyawdie/helm-learn.git Change directory to creating-charts cd helm-learn/creating-charts Spin up the environment using docker-compose. docker compose up -d --build SSH into the container. ubuntu ssh -o StrictHostKeyChecking=no -o NoHostAuthenticationForLocalhost=yes root@localhost -p 2222
# password: test123 Generate a chart directory along with sample files. helm create my-n8n View the structure of the generated directory. tree .

# Output should look similar to this
#`-- my-n8n
#    |-- Chart.yaml
#    |-- charts
#    |-- templates
#    |   |-- NOTES.txt
#    |   |-- _helpers.tpl
#    |   |-- deployment.yaml
#    |   |-- hpa.yaml
#    |   |-- ingress.yaml
#    |   |-- service.yaml
#    |   |-- serviceaccount.yaml
#    |   `-- tests
#    |       `-- test-connection.yaml
#    `-- values.yaml We'll only be using , , and so we can remove the rest since we'll be adding our own manifest files. Chart.yaml values.yaml my-n8n/templates/NOTES.txt my-n8n/templates/_helpers.tpl rm -rf my-n8n/templates/*.yaml my-n8n/templates/tests Update the appVersion in Chart.yaml to "1.27.2" & clear the contents of my-n8n/templates/NOTES.txt file then update with the following. nano my-n8n/Chart.yaml
# appVersion: "1.27.2"

nano my-n8n/templates/NOTES.txt
# Welcome to n8n.
# Wait a few minutes until the status changes to RUNNING.
# After it is ready, access it from: http://localhost:2223 Update the file with the following data. values.yaml # Default values for my-n8n.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

replicaCount: 1

image:
  repository: n8nio/n8n
  pullPolicy: IfNotPresent
  # Overrides the image tag whose default is the chart appVersion.
  tag: "1.27.2"

containerPorts:
 - name: http
   port: 5678

service:
  type: NodePort
  port: 30200

livenessProbe:
  httpGet:
    path: /
    port: http
readinessProbe:
  httpGet:
    path: /
    port: http

autoscaling:
  enabled: false
  minReplicas: 1
  maxReplicas: 100
  targetCPUUtilizationPercentage: 80
  # targetMemoryUtilizationPercentage: 80

# Additional volumes on the output Deployment definition.
volumes:
- name: n8n-data

persistence:
   claimName: n8n-data

# Additional volumeMounts on the output Deployment definition.
volumeMounts:
 - name: n8n-data
   mountPath: "/home/node/.n8n" Create the , and, files inside the folder. deployment.yaml service.yaml pvc.yaml my-n8n/templates # my-n8n/templates/pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: n8n-data
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi # Adjust the size as per your requirement # my-n8n/templates/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: n8n
spec:
  replicas: 1
  selector:
    matchLabels:
      app: n8n
  template:
    metadata:
      labels:
        app: n8n
    spec:
      containers:
      - name: n8n
        image: n8nio/n8n
        ports:
        - name: http        
        - containerPort: 5678
        volumeMounts:
        - name: n8n-data
          mountPath: /home/node/.n8n
      volumes:
      - name: n8n-data
        persistentVolumeClaim:
          claimName: n8n-data # my-n8n/templates/service.yaml

apiVersion: v1
kind: Service
metadata:
  name: n8n
spec:
  type: NodePort
  ports:
  - port: 5678
    targetPort: 30200
    protocol: TCP
  selector:
    app: n8n Now, let's parameterize these using the go-template language to convert them to templates. Helm will fetch the appropriate values from the file to generate the manifest that will be deployed on K8S. values.yaml # my-n8n/templates/pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: {{ .Values.persistence.claimName }}
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi # Adjust the size as per your requirement # my-n8n/templates/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ printf "%s-%s" .Release.Name .Chart.Name  }}
spec:
  replicas: 1
  selector:
    matchLabels:
      app: n8n
  template:
    metadata:
      labels:
        app: n8n
    spec:
      containers:
      - name: n8n
        image: {{ printf "%s:%s" .Values.image.repository .Values.image.tag  }}
        ports:
        {{- range .Values.containerPorts }}        
        - name: {{ .name }}
          containerPort: {{ .port }}
        {{- end }}        
        volumeMounts:
        {{- range .Values.volumeMounts }}
        - name: {{ .name }}
          mountPath: {{ .mountPath }}
        {{- end }}
      volumes:
      {{- range .Values.volumes }}      
      - name: {{ .name }}
        persistentVolumeClaim:
          claimName: {{ $.Values.persistence.claimName }}
      {{- end }} # my-n8n/templates/service.yaml

apiVersion: v1
kind: Service
metadata:
  name: {{ printf "%s-%s" .Release.Name .Chart.Name  }}
spec:
  type: {{ .Values.service.type }}
  ports:
  - port: 5678
    targetPort: 5678
    nodePort: {{ .Values.service.port }}    
    protocol: TCP
  selector:
    app: n8n Ensure that you're in the directory that contains the chart then run the linter. my-n8n helm lint my-n8n Install the chart. helm install my-n8n ./my-n8n Wait until the deployment is complete, you can continually check using the following command. kubectl get all After the status has changed to running, you should be able to access it in your browser from: http://localhost:2223 Recap Great effort! You just learned how to create and configure a Helm chart and then deploy it to a Kubernetes cluster!

Helm 101: How to Create Helm Charts

A Roadmap for User Empowerment in the Dark Pattern Landscape

I remember when I started working as a DevOps Engineer. For me, ” best practices” was the most sacred phrase. I searched for best practices not only when I wanted to know how to do something. I searched for best practices to get inspiration for what I should do. In hindsight, big mistake. It happened because I didn’t have a clear goal. When you don’t have a clear goal, you’ll try to see what the experts do and copy. You’ll end up embracing their best practices without knowing why they did them. I’ll share with you here why “One-Click Environment” is the ultimate goal. DevOps As a bonus, I’ll share a framework to achieve it fast.‍ The ultimate DevOps goal - One-Click Environment Looking back, the goal you should set is simple: Create an environment in “One-Click”. I’m saving you years of confusion that I had to go through. Why is this the ultimate goal, you ask? Three reasons: It makes it easy to test changes It makes it clear what should be automated It improves the system’s recoverability What do I mean by “Environment”? A ‘clean’ and working version of the entire system. The most popular environment is the Production environment, which serves the clients. There are static testing environments, such as ‘dev,’ ‘staging,’ ‘uat,’ and more. There are also ephemeral testing environments, such as Pull-Request-Environments, Git-Branch-Environments, Developer-Environment, etc. Why does it make it easy to test changes? The company with the fastest development speed I ever saw was a supply-chain startup. They deployed high-quality code to production a lot, every day, with no downtime. How? We deployed ephemeral environments for every pull request. The environments were identical to production. After running automated tests, they terminated. We used Pulumi (Typescript) on AWS and documented how to change the environment. This way developers took part in contributing to the environments. Programming is not Mathematics Edsger Dijkstra was one of the pioneers of computer science. He envisioned programming as a mathematical discipline. He thought programmers would mathematically prove their code works. When was the last time you wrote a mathematical proof for your code? Probably never. Programming is Science Instead, you took the scientific approach: You ran some tests to see if your code worked as expected. And how do you run tests? On an environment, of course! The easier it is to create an environment, the faster you’ll be able to run your tests. The ‘cleaner’ your environment is, the more trust you’ll have in the test results. Why does it make it clear what should be automated? Another startup we work with has 15 Kubernetes clusters with 2,200 nodes on GCP - All created manually! Developers asked for support many times a day; "Create this DB", "I need a new NodePool", etc. With every new request, we had to ask - "Should this be automated?" We ended up automating everything required for every new environment. How? We created a Pulumi Typescript codebase and imported the entire infrastructure into it. On top of that, developers felt comfortable contributing to it, as it was a Typescript project. The “should this be automated?” mental struggle I asked myself at least 1,836 times, “Should this be automated?” on lots of things. Sometimes, I decided to automate nonsense. If you want to understand if it's worth automating, ask yourself two questions: Is it going to happen again? Will automating it take less time than doing it manually? Don’t rely on your memory You’ll need to remember every ad-hoc modification you did to an environment. If a change isn’t done as part of the “One-Click Environment” automation, you’ll have to rely on your memory and do it again. Imagine a developer creating a new environment, running its tests, only to find out the DB isn't there. Someone created it manually in the other environments. Bottom line, how do “One-Click Environments” guide automation? Next time, you ask yourself, “Should this be automated?” If it’s part of what a new and clean environment needs: Easy YES If not: A strong maybe. By the way, maybe you want to automate it, but you’re drowning in so many requests that it’s impossible. In that case, send your management . this article It's about calculating how much DevOps capacity your company needs. Maybe it’ll help you understand how much DevOps capacity you need. Why does it improve the system’s recoverability? An IoT startup we worked with had 5 clients, with an per client. AWS account It was supposed to be the same system per client, but it wasn’t! Each account’s production was created with Terraform (Terragrunt) and Ansible. But, there were so many ad-hoc changes it took about 2-4 days to create a full environment from scratch. We decided to use Jenkins and created a pipeline that automated everything. When we finished, you could deploy a full environment from scratch in 50-minutes. (after some parallelization, it went down to 20-minutes) You should have heard the sigh of relief the team had when the demo finished — ”No more fear of not recovering from a production incident!”. Create a new environment and route traffic to it Think about your production — what would it take to create it from scratch? If your answer is “I don’t know,” it’s most likely because some things were created manually or ad hoc. If your answer is “one-click,” we are hiring. Please click this link asap: . Senior DevOps Engineer Position at MeteorOps Imagine a production failure that requires creating a new environment and finding out you can't. Some things were modified manually. Or, as the poet Capone-N-Noreaga wrote - “Oh no, oh no, oh no, no, no, no no.” When you have “One-Click Environments”, you can deploy a new environment fast and use it instead of the old one.‍ It also improves high-availability When you can create an environment from scratch, things become easier: creating a multi-region setup creating an active-active setup creating an active-passive setup You can deploy many environments in different locations and route traffic to an environment based on your needs. TPCS - A useful framework to achieve a One-Click Environment Tools, Pipeline, Contributions, State ‍ It all boils down to 4 things you should be doing: You should choose the tools to manage data, provision, deploy, configure, secure, test, monitor, and automate Then, you should build the pipeline that uses the tools to create the environment You should also make it easy to contribute to the pipeline that creates an environment And you should continuously reconcile the state of the system to its desired state Principles for Choosing Tools Choose tools that answer the below requirements: More native integrations per tool, less glue required — Makes building the pipeline easier (e.g., AWS) Popular tools with active communities make documentation easier (e.g., ). Tools with a declarative syntax are self-documenting and save you some hustle (e.g., Terraform) Kubernetes Tools with native state management will save you time reconciling the state of the system (e.g., Terraform) Tools with extensive APIs will make it easier to give the developers more ownership (e.g., Pulumi) Guidelines to build the pipeline This is where you’re flexibility is your number one priority: Choose a flexible automation platform (e.g., Jenkins) Create one pipeline and make it possible to pass parameters to it Manage the pipeline’s code straight in Git Bonus: Parallelize its stages to speed it up Make it easy to contribute Describe the desired state of the system in a Git repository and make it easy for developers to contribute Make it clear where to find infra-related stuff, deployment-related stuff, etc Write good documentation ‍ Good documentation answers these questions: How to provision a resource? How to deploy a workload? How to configure the system? How to secure the system? How to test changes? How to monitor a workload? How to automate a process? How to manage the data’s lifecycle? (e.g., Run DB migrations) Reconcile the state of the system This step is made easier if you chose idempotent tools with state management, and made harder if you didn’t! (choose idempotent tools) The guiding principle here is simple. If you run the pipeline twice with the same parameters, nothing should happen the second time. That’s it; you’re good to go! But first… A Recap! Without a useful goal, you might embrace “best practices” that aren’t good for you. The most useful goal for a DevOps Engineer is being able to create an environment with “One-Click”. Because it makes it easy to test changes, And It makes it clear what should be automated, And It makes it easy to recover the system. A framework that helps achieve this goal is TPCS: Tools, Pipelines, Contributions, State ‍ Whenever I think about going forward without a goal, I’m reminded of this gem from ‘Alice in Wonderland’: “Alice: Would you tell me, please, which way I ought to go from here? The Cheshire Cat: That depends a good deal on where you want to get to. Alice: I don't much care where. The Cheshire Cat: Then it doesn't much matter which way you go. Alice: ...So long as I get somewhere. The Cheshire Cat: Oh, you're sure to do that, if only you walk long enough.” ― Lewis Carroll, Alice in Wonderland‍ Also published . here

One-Click Environments: The Ultimate DevOps Goal and How to Achieve It with TPCS Framework

Communities are hard. They are hard to build, hard to maintain, and hard to grow. But, building communities has been one of the most rewarding things in my career, because I met so many amazing people and was forced to learn and do things out of my comfort zone. I remember over 10 years ago I attended my first small tech conference - CouchConf in Berlin. Luckily there was a BerlinJS Meetup happening around the same time and I was blown away by the community and the people. They have a GitHub repository set up for the website and talks are submitted as GitHub Issues. I was amazed by the simplicity and transparency of the process, so I forked the repo and founded BarcelonaJS a few weeks later. This was the start of my own organizers' journey. A little anecdote of a regular and very frustrating experience: You spent hours preparing, communicating, finding and inviting speakers, finding and securing a date & venue, talking to sponsors for food and drinks all to put together a great event. And when the time comes you're sitting there alone or with a fraction of the people you thought would come, because Meetup says "150 people RSVPed YES". And in one rare occasion that was just bad luck with the weather, but more often when I talked to people afterward I heard this: This is amazing, I wish I'd been there, but I did not know! This phrase was the motivation for me to start exploring GitHub as a community tool because GitHub is one of the most amazing platforms for automation and that's what you need to do as an organizer: automate the crap out of everything to publish the event on Eventbrite, Meetup, Twitter, Facebook, Telegram Groups, WhatsApp, Email, Calendar, etc. etc. etc. and do that 2 weeks before, 1 week before, 3 days before, 1 day before, 1 hour before the event so nobody can say afterward: "I did not know about this". Because in the end, you're not doing this for yourself but for the community. During my travels, I came across Node.js and JavaScript communities on Meetup with thousands of members, but not a single upcoming or recent event. This can happen for many reasons, but it's often because the organizers do not have time or have moved on to other things, and it's hard to find a successor to keep things running. Meetup and other platforms are great for the discovery of communities and events, but they make it hard for members to reach out to the community in case an organizer is no longer active and to take over / revive the community. As a developer, I spend a lot of time on GitHub and am familiar with the tools and workflows, so I started exploring on how to use GitHub as a community platform. Benefits of using GitHub for Community Building Open Source & Open Community The first and most obvious benefit is that public repositories on GitHub are Open Source. This means all the content, issues, and discussions are public and can be forked, copied, and reused by anyone. This is great for communities because it means that if the community is abandoned, anyone can fork it and continue the work. It also means that if you want to start a new community, you can fork an existing one and adapt it to your needs. GitHub has user/team/organization management built in, so you don't need to build anything yourself. It's easy to invite someone into the organization or to add teams with different permissions of the organization. Most of us know how to use GitHub and visit the site on a daily basis, so there's no need to bookmark additional sites for database administration, content management or other tools. With GitHub Actions, we can run automated tasks on a schedule or on demand, and with GitHub Pages we can host our community website for free. Building in Public & Transparency For me, one of the most important benefits of building a community on GitHub is full transparency and open communication. Everything[1] is public, so there's no need to worry about who has access to what. This means that anyone can contribute to the community, and anyone can see what's going on. This is great for building trust and for building a community that is inclusive and welcoming to everyone. My aim with communities like BarcelonaJS, CDC etc. was/is to create free and open spaces for developers to share and connect. And "free" is where transparency comes in. In the past, I always kept my hands off financial contributions. If a company wanted to sponsor, they could order food or drinks directly to the venue, but I wouldn't facilitate. Thanks to the , this has become much easier and we're now able to accept financial contributions and make them transparent to the community. These are used for example to pay for the domain(s), to get food and drinks, run ad campaigns etc. Open Collective [1] of course, you can also create a private repo for internal organizers discussions etc. Drawbacks & Caveats GitHub is not a Community/Event Platform like Meetup, so there are some caveats. I've grown used to treating Issues as "Events" or "Talk Proposals" and GitHub Issue Forms to structure submissions. But it's not ideal and takes time for newcomers to understand "Create an issue to submit a talk". There are no "comfort features" to pick a date, location on a map, etc. and trigger a simple email notification to hundreds of people. The Open (Developer) Community This entire concept is primarily focusing on developers and engineers, as it evolves around GitHub and IssueOps. To give an idea of my previous experience, here are a few communities and conferences I've helped build: , 2012 - 2018 BarcelonaJS Hackers & Founders Barcelona, 2012 - 2015 Node.js Barcelona Meetup Group, 2012 - 2018 Couchbase Barcelona Meetup, 2012 - 2015 NodeConf Barcelona, 2015, 2016, 2017 MediterráneaJS, 2015 2018 - 2021 CyprusJS 2020 - present Cyprus Developer Community While building these, I've continuously worked on a set of tools, workflows and automation to make the lives of organizers easier, because it's such a tough and often thankless job. So here's my of how I construct a public community on GitHub. Open Community Concept Labels & Structure The first step is to set up a GitHub organization and create two repositories: events talks The names are obvious: in the events repository are , and in the talks repository are templates for submitting . Talks can be linked to events to build up an agenda and, if you manage to get engagement from the community (remember: it's hard!), comments and reactions such as 👍 or ❤️ can be used to vote on talks. templates for creating new events talk proposals You can also use a to manage the event lifecycle through the proposal, scheduling and announcement phases: GitHub Project In Cyprus, we added labels for the different regions on the island, but most importantly an "Approved" label is needed. All new issues are created with the "Event" label, but only someone with "triage" permission (organizers team) can "approve" the event. This is important to avoid spam and to make sure the event is relevant. Now that there's an organization, some repos with issues and some structure in place, it's time to automate. GitEvents / goes and started with the name as a collaboration "hack weekend" between the London Node User Group (LNUG) and the Barccelona Node.js Group. Back then, GitHub Actions didn't exist and we tried to use Webhooks for issues to build up structured data for GitHub Hosted websites based on Meetup.com data. The setup was cumbersome and the project was abandoned for a while. GitEvents GitEvents on GitHub way back (2014) gitup Today, is a simple set of GitHub Actions to automate issue workflows. "Git Ops" for meetups and events. All that's needed is a GitHub Organization and a GitHub App. Some of the features are: GitEvents : Any interaction with GitHub repositories, issues or discussions triggers a workflow to invite the user to the GitHub organization and adds them to the "Community Members" team. The permissions are the same as for the public, but a little "growth & engagement hack" is that you can @-mention all community members in issues. This is great for announcements, but shouldn't be abused, otherwise you quickly lose members. Inclusive Org : I put together a set of simple templates for events, talks, code of conduct replies etc. to quickly get started with GitEvents. Issue Templates : are re-usable GitHub Workflows to automate marketing and common tasks such as emailing/tweeting/blueskying members, creating/updating events on Discord, EventBrite, Meetup etc. Broadcast : is a GitHub Action to generate iCal files for events. is a standard for calendar events. People can just add this as a subscription to their calendar to keep up to date with community events. We created a redirect to the github file, so people can subscribe to the calendar with a simple link: . ICS iCal https://calendar.cdc.cy Everything is "plug and play" so you can pick the Actions you like and it's relatively easy to compose them into a workflow. For examples, check out the . Cyprus Developer Community Workflows If you'd like to get started with GitEvents and need some help, please reach out on our GitEvents is a work in progress and there's always especially with integrations to other platforms etc. If you want to help, please get in touch. Discord Server a lot to do GitHub Issue Forms Issue Forms are still a relatively little-known feature on GitHub. Instead of a regular Markdown templates, a with a form configuration. YAML file can be provided This is pretty cool to get structured input, but once saved as "Issue", the data is semantically useless because it's just Markdown. I've experimented with Milestones, Markdown headers, Labels etc. to add semantic information like dates, locations etc. to an issue, but nothing worked well. So I started building . This helps to parse an issue that was created through a form to extract dates, links, images, lists etc. and convert them into structured JSON data. This can directly be passed on to other platforms like Discord, EventBrite, Meetup, etc. or used in mailings, tweets etc. GitHub Issue Forms Body Parser The as a library to parse any Markdown text. Only recently I realized entire files can be parsed for structuring data for a website: Issue Forms Body Parser is also available on npm README.md query ($organization: String!, $repository: String!) {
  repository(owner: $organization, name: $repository) {
    id
    name
    object(expression: "main:README.md") {
      ... on Blob {
        text
      }
    }
  }
} This is the query to retrieve file content from the branch of a repository, and you can pass that into the "body parser": main const structuredData = await bodyParser(readmeFile()?.repository.object.text) Instead of keeping yet another copy of your community description, you can now fetch the section from the file and use it on your website. About README.md GraphQL API With the latest website I wanted to explore and push the boundaries of what's possible with Issues, files and structured JSON data and I'm fairly pleased with the result: https://cdc.cy README.md most of the website content is fetched from or files on GitHub; everyone can edit, no CMS or account etc. required README.md .json upcoming and past events are based on GitHub issues (approved & event-labelled issues on the repo) events organizers are fetched from GitHub Team Members Events can be annotated/enhanced with proper location data from a "common locations" file Speaker profiles are entirely based on GitHub User Profiles, we can fetch avatars, bio (readme), location, etc. and build pretty speaker profile pages We can display some stats such as "number of members of the organization", "number of past/upcoming events" etc. All of these features were possible through the and by parsing the Markdown files with the body parser. GraphQL API Summary & Outlook I've been working on this concept for a while and it's still changing shape every once in a while. But the basic ideas I've adopted from BerlinJS haven't changed: : everything is public and transparent, and everyone is welcome (as long as they follow the Code of Conduct) Open Community Events and Talks/Proposals are issues in a repository Labels help with structure and automation Building all of this has taken a lot of time and energy and there are still lots of things missing I don't have time for: proper email integration with schedules, reminders, etc. finalize EventBrite integration add Meetup integration add WhatsApp/Telegram/Slack integration improve issue handling, and automatic comments (ie. Code of Conduct reminder, follow-up reminder etc.) If you think this can help you and your community and want to get involved in piecing the puzzle together, please reach out on the , on or directly on one of the . gitevents Discord Server GitHub Discussions GitHub Issues If you're in or , please join and support the local developer groups. Cyprus Barcelona Random Organizers Thoughts, Tips & Tricks from personal experience Venues: picking a company office as a venue is easy, but has lots of drawbacks. It's easy to manipulate people once you have them in the office (look at our cool place, we even have a cocktail bar!). Remember the company has different motives than you (recruiting, marketing, etc.). Sometimes there may even be conflicts, that people aren't allowed to visit the competitors' office. If possible, I prefer "neutral" co-working and event spaces and thanks to Open Collective you can get sponsorships to pay for the venue with fair (recruiting/marketing/etc) rules for everyone. Reminders: we're all busy and it's easy to forget things. Not everyone is as engaged, motivated & psyched about the event as you are, so regular reminders keep people engaged and help to build a habit. Find a good cadence for reminders, and do not overdo it and spam people. Different media work for different people, so I try to cover as many as possible. Scarcity "I've noticed that announcing the event just one week before it's happening and having a limited amount of seats works better then releasing month in advance with 100+ capacity" – Dmitry Zaets, BarcelonaJs Perks: "Giveaways are fun, and giving away tickets to conferences and other stuff can be nice perks for attending" – Dmitry Zaets, BarcelonaJs Consistency: "Establish a realistic schedule from the outset. Whether it's a monthly meetup or a quarterly conference, consistency is key. Create a roadmap, allocate responsibilities, and stick to the plan. This not only keeps your audience engaged but also helps in building a reliable community." – Federico Rampazzo, CDC.cy Finding Speakers: "Don't be afraid to approach experts who might be willing to share their insights. A lot of your members are likely to have interesting stories worth sharing! It can be an enriching experience for them as much as for the community. Taking photos, videos, audio recording of the events is valuable and help the speakers in their speaking career, as well as increasing the reach of the event." – Federico Rampazzo, CDC.cy

GitHub and the Art of Building Open Communities

গিটহাব এবং আর্ট অফ বিল্ডিং ওপেন কমিউনিটি

GitHub und die Kunst, offene Communities aufzubauen

GitHub y el arte de construir comunidades abiertas

GitHub et l'art de créer des communautés ouvertes

GitHub और खुले समुदायों के निर्माण की कला

GitHub とオープン コミュニティを構築する技術

GitHub와 개방형 커뮤니티 구축 기술

GitHub e a arte de construir comunidades abertas

GitHub и искусство создания открытых сообществ

GitHub ve Açık Topluluklar Oluşturma Sanatı

GitHub và nghệ thuật xây dựng cộng đồng mở

GitHub 和构建开放社区的艺术

Stories, News & Mentions about NODEIO

Nodeio’s Stories on HackerNoon