| { | |
| "AWSTemplateFormatVersion": "2010-09-09", | |
| "Description": "Infrastructure for the Spring Boot + Docker + CFN sample", | |
| "Parameters": { | |
| "Version": { | |
| "Type": "String", | |
| "Default": "1.0.0" | |
| } | |
| }, | |
| "Resources": { |
| Running shell scripts that have contain sudo commands in them from jenkins might not run as expected. To fix this, follow along | |
| Simple steps: | |
| 1. On ubuntu based systems, run " $ sudo visudo " | |
| 2. this will open /etc/sudoers file. | |
| 3. If your jenkins user is already in that file, then modify to look like this: | |
| jenkins ALL=(ALL) NOPASSWD: ALL | |
| 4. save the file by doing Ctrl+O (dont save in tmp file. save in /etc/sudoers, confirm overwrite) | |
| 5. Exit by doing Ctrl+X | |
| 6. Relaunch your jenkins job |
| # I moved this all to https://github.com/CCOSTAN/Home-AssistantConfig - I won't be updating this file anymore. | |
| homeassistant: | |
| name: Bear Stone Run | |
| latitude: !secret homeassistant_latitude | |
| longitude: !secret homeassistant_longitude | |
| elevation: !secret homeassistant_elevation | |
| unit_system: imperial |
While the following structure is not an absolute requirement or enforced by the tools, it is a recommendation based on what the JavaScript and in particular Node community at large have been following by convention.
Beyond a suggested structure, no tooling recommendations, or sub-module structure is outlined here.
lib/ is intended for code that can run as-issrc/ is intended for code that needs to be manipulated before it can be used
This gist will show how to setup Raspbian Stretch as a headless Bluetooth A2DP audio sink. This will allow your phone, laptop or other Bluetooth device to play audio wirelessly through a Rasperry Pi.
A quick search will turn up a plethora of tutorials on setting up A2DP on the Raspberry Pi. However, I felt this gist was necessary because this solution is:
When hosting our web applications, we often have one public IP
address (i.e., an IP address visible to the outside world)
using which we want to host multiple web apps. For example, one
may wants to host three different web apps respectively for
example1.com, example2.com, and example1.com/images on
the same machine using a single IP address.
How can we do that? Well, the good news is Internet browsers
I have been an aggressive Kubernetes evangelist over the last few years. It has been the hammer with which I have approached almost all my deployments, and the one tool I have mentioned (shoved down clients throats) in almost all my foremost communications with clients, and it was my go to choice when I was mocking my first startup (saharacluster.com).
A few weeks ago Docker 1.13 was released and I was tasked with replicating a client's Kubernetes deployment on Swarm, more specifically testing running compose on Swarm.
And it was a dream!
All our apps were already dockerised and all I had to do was make a few modificatons to an existing compose file that I had used for testing before prior said deployment on Kubernetes.
And, with the ease with which I was able to expose our endpoints, manage volumes, handle networking, deploy and tear down the setup. I in all honesty see no reason to not use Swarm. No mission-critical feature, or incredibly convenient really nice to have feature in Kubernetes that I'm go
| import React, { Component } from 'react'; | |
| import './App.css'; | |
| class LoginPage extends Component { | |
| constructor() { | |
| super(); | |
| this.state = { | |
| username: '', | |
| password: '', | |
| error: '', |
| options: | |
| docker: true | |
| pipelines: | |
| branches: | |
| master: | |
| - step: | |
| image: google/cloud-sdk:latest | |
| name: Deploy to production | |
| deployment: production | |
| caches: |
| options: | |
| docker: true | |
| pipelines: | |
| branches: | |
| master: | |
| - step: | |
| image: google/cloud-sdk:latest | |
| name: Deploy to production | |
| deployment: production | |
| caches: |