Our product, built exclusively for the accounting and bookkeeping profession, combines client collaboration (portal) and internal workflow management solution to help firms track and manage the critical tasks related to their work

Client Hub Solutions

Bitcoin (BTC) / Bitcoin Cash (BCH). Pt 2

Part I. Problem and first solutions. project launched in 2004 now became an industry standard for browser automation. However if your QA department is relatively big, sooner or later you will face to recommended limitations. In this article I would like to tell you how to create a scalable and fault-tolerant Selenium solution easily. Selenium Selenium architecture Problem Selenium architecture radically changed several times since 2004 when its first prototype was created. Current Selenium architecture introduced in 2.0 branch is called Selenium Grid. It works like the following: Usually a cluster consists of two daemon applications: Selenium Hub and Selenium Node. A is an API that handles user requests and redirects them to respective nodes. A is an actual request executor launching browser processes and requesting desired test steps from them. In theory an unlimited number of Selenium Nodes can be connected to one Selenium Hub and every node can launch any installed browser. But what’s in practice? hub node Such architecture has a weak part. Selenium Hub is a single browser access point. If it goes down or does not respond all browsers become unavailable. The same happens if a datacenter with hub is powered off or its network fails. Selenium Grid does not scale well. Our 5+ years of Selenium cluster expertise show that even under moderate load a hub can work with a limited number of connected nodes. Depending on hardware even dozens of connected nodes can dramatically increase hub response time. No quoting functionality. You can’t create users and specify browser consumption limits. Solutions The simplest scalable approach is to use multiple Selenium Hubs distrubuted across multiple datacenters. However standard Selenium libraries can only work with one Selenium hub. We need to teach them to work with such distributed system. Client-side load balancing An initial approach we successfully used several years ago was a client library that did client-side load balancing. This is how it works: We launch multiple Selenium Hubs and respective Nodes in multiple datacenters. A list of hub hostnames with supported browsers is saved to file. Selenium user attaches a small client library as a dependency to his tests and requests a Selenum session using the library. The library reads the file with hubs and randomly selects one of them having desired browser. Then it requests a browser using standard Selenium client. If session is created successfully then test steps start executing. Otherwise the library tries another hub host until a session is created. Different hubs can contain different quantities of browsers. To deliver uniform load distribution we need to assign different weights to hub hosts and then select these hosts according to their weights. If the client fails to create a session on every hub from the list — it should throw an error. A single line of test code (new session request) should be changed to support that library. For example in Java tests a new session request may look like that: WebDriver driver =new RemoteWebDriver("http://my-hub.example.com:4444/wd/hub", caps); All classes in this code come from a standard Selenium Java client. E.g. if a client-side library is called SeleniumHubFinder a new session request will look like: WebDriver driver = SeleniumHubFinder.find(caps); No Selenium hub URL is used in updated code — this information is stored inside client library. That’s it! This approach worked for years. Hundreds of software testers in our company were satisfied. What are the drawbacks of using client library? A supplementary library should be added to every test project. You can’t launch your test without this library. A separate client library should be implemented for each language. E.g. Javascript, Java or Python Selenium tests may exist in your company. In that case you need to support several client libraries and ensure that hub lists are in sync. That’s why a server-side solution is necessary. Server-side load-balancing Relying on our experience with client-side solution we introduced the following natural requirements to server-side one: The server should look as Selenium hub to client libraries. To achieve this it should implement . Selenium JsonWire protocol Any number of server nodes can be installed in any datacenter. They can be installed behind any software or hardware load balancer. Server instances are stateless. They don’t use neither database server nor queue server to share state. Server should support multiple users and quoting. We called the server — GridRouter because the only thing it does is routing user requests to correct Selenium Grid Hub. Here’s the new architecture: The load balancer distributes user requests across multiple GridRouter instances. Every GridRouter instance stores information about all available Selenium Hubs like client-side library did. To handle new session request GridRouter uses the same random distribution algorithm. As you probably know every new browser session in Selenium automatically obtains an ID called session ID. According to Selenium JSONWire protocol this ID is always passed to request. GridRouter appends information about selected Selenium Hub to this session and returns enriched session ID to user. After session is obtained GridRouter extracts used Selenium Hub information from enriched session ID on each following request and simply proxies it to a corresponding hub. Since all session information is stored in its ID there’s no need to synchronize GridRouter instances. This is why GridRouter is stateless. GridRouter Initially we implemented GridRouter using Java, and . Its source code is available on . This implementation is using a plain text properties file to store users list and an XML file to save a list of Selenium hubs for each user. A typical users list (by default ) looks like the following: Jetty Spring Framework Github /etc/grid-router/users.properties user:password, useruser2:password2, user Every line corresponds to one user. Passwords in current implementation are stored without any encryption. This is because we consider that users are mainly needed to account browsers consumption by different teams. Selenium hub lists are stored in XML files of the following format (by default ): /etc/grid-router/quota/*.xml <qa:browsers xmlns:qa="urn:config.gridrouter.qatools.ru"><browser name="firefox" defaultVersion="33.0"><version number="33.0"><region name="us-west"><host name="ff33-hub-1.example.com" port="4444" count="5"/></region><region name="us-east"><host name="ff33-hub-2.example.com" port="4444" count="5"/></region></version><version number="37.0"><region name="us-west"><host name="ff37-hub-1.example.com" port="4444" count="3"/><host name="ff37-hub-2.example.com" port="4444" count="4"/></region><region name="us-east"><host name="ff37-hub-3.example.com" port="4444" count="2"/></region></version></browser><browser name="chrome" defaultVersion="42.0"><version number="42.0"><region name="us-west"><host name="ch42-hub-1.example.com" port="4444" count="10"/></region><region name="us-east"><host name="ch42-hub-2.example.com" port="4444" count="10"/></region></version></browser></qa:browsers> You can see that we define available browser names, their versions and a set of hosts distributed across multiple regions. A region in our terms is just a datacenter. Information about datacenters is mainly needed if one datacenter goes down. We select a host from another datacenter if the first session attempt fails. This approach increases the probability of faster Selenium session creation. Using GridRouter in tests As I previously said GridRouter implements standard Selenium protocol and is fully compatible with all existing client libraries. The topic we have left is how to authenticate in GridRouter i.e. specify which quota we want to use. All Selenium client libraries support only one authentication method — . That’s why GridRouter supports only this method too. Usually Selenium hub url is like the following: Basic HTTP Authentication http://example.com:4444/wd/hub As you probably know basic HTTP authentication username and password can be encoded to URL like that: http://username:password@example.com:4444/wd/hub This is the only change you need to do in your code to use GridRouter instead of Selenium Hub. The majority of Selenium client libraries including Java and Python implementations work with such notation. Some Selenium-based Javascript tools however require you to specify username and password as separate configuration options. Selenograph GridRouter allowed us to stop using client-side libraries. It gave users with different languages access to a scalable Selenium installation. To scale GridRouter installation you just need to add more Selenium hubs to its XML configuration — all changes are applied automatically without service restart. To serve more requests per second you also need to add GridRouter hosts behind load balancer. Our experience shows that GridRouter works perfectly when total percentage of used browsers of any version is below ~80%. Problems begin when the peak load arrives and browser consumption grows up to 90–100% of total capacity. In this case the random uniform session attempts distrubution becomes inefficient. We are trying to obtain Selenium session on fully occupied hub too often and do attempts to several hubs before returning session to user. This increases session start time and slows down tests. Our next stage in Selenium cluster development aimed to resolve the issues above was a new product called . Selenograph is a Java server based on GridRouter source code fully compatible with its configuration files. The main differences are: Selenograph It is stateful. To be more efficient on high loads Selenograph is using more sophisticated algorithm of choosing hub hosts. The main idea is to dynamically adjust hub host weight by considering total number of already running sessions. This number should be saved to storage shared among Selenograph nodes. We use as such storage. MongoDB It provides more statistics and user-friendly interface. For example Selenograph API can return total number of concurrently running sessions at each moment of time. Although Selenograph is a stateful solution it is confirmed to work correctly under high load allowing to serve hundreds of requests per second to every instance. Conclusion In this part I told you about standard Selenium scalability problems and how they can be resolved with minor changes to your cluster architecture. In the next part we’ll discuss topics like: How to prepare worker nodes for big cluster so it scales well Some thoughts about nearest Selenium future How to run Selenium inside Docker containers What are the new open source tools that will help you to deploy an efficient Selenium cluster with low resource consumption Stay tuned…

Selenium testing: a new hope

Add Additional Data Protections to G Suite with the Virtru SDK I’m not a developer. I know a little JavaScript and Python — enough to write a couple of basic scripts to help with some of my more mundane tasks — but I certainly don’t have the skills or know-how to write actual software. What I do know, however, are my customers and the challenges they face in keeping their data secure. So when we released the , touting its ease of use, I was skeptical. How hard is this going to be for my customers to integrate into their existing workflows? Could someone with my limited coding skills build something with this? Let’s find out! Virtru SDK TL; DR: Yes. It actually is really easy to add the Virtru SDK to your project, as I’ll demonstrate through the construction of a “Protect & Share” Google Docs add-on. See the completed project here . Identifying a Project To find a project that would both add value to my current workflows and demonstrate the functions of the Virtru SDK, I asked myself three questions: What are my most common workflows? Well, we’re a G Suite shop, so let’s start there. I spend of time in Google Docs. Whether taking notes, writing reports, developing customer-facing documentation, or drafting this very blog post, it’s a rare day that I don’t work in at least one Google Doc. And since these documents can be internal-only or customer-facing, I’m always trying to figure out how best to share them. a lot Could these workflows use additional layers of data protection? Google has some great protections and controls for sharing Docs content with other G Suite users, but the experience sharing outside the Google ecosystem has always been lacking. If you want to share a Doc with a non-Google user, you’re forced to make your data semi-public on the internet with no guarantee that it’ll only be accessed by authorized parties. Even for my least-sensitive documents, I’m not thrilled with this requirement; for my most sensitive content, it’s a showstopper. What’s the lowest barrier to entry? When I think “add features to G Suite”, I typically think “Chrome Extension”. But recently I’ve been experimenting with , and it’s clearly the more compelling solution for this use case. The code runs directly within G Suite, so I won’t have to build and package an extension. It’s JavaScript & HTML-based, so it will support Virtru’s browser JS SDK. And it’s designed to do exactly what I ultimately want to do: Google Apps Script build add-ons to extend Google Sheets, Docs, & Slides. Goal To that end, I’ll need to add the following functions to the Docs UI: To build a Google Docs add-on that will allow me to generate a secure, encrypted copy of my Google Docs content and share it privately with authorized users. - Capture Google Doc content in a PDF. - Encrypt that PDF with policy controls set by the user such as document watermarking, expiration date, and disable re-sharing. - Download the encrypted PDF, OR - Send the encrypted PDF as an email attachment. The first, third, and fourth functions above are all straightforward and easily accomplished with the tools available in Google Apps Script. The only new functionality I need to add is to encrypt the document and apply my access controls. Building It When In Doubt, Copy & Paste With zero experience writing a Docs add-on, I’ve decided to simply copy from Google’s own documentation, rip out the parts I didn’t need, then add my own code. this sample translation project A basic add-on has two parts: server-side code running within the Google Apps Script environment — ‘Code.gs’ — and client-side code running directly on the page — ‘virtruSidebar.html’. I want to encrypt client-side, so I can copy some sample code from the Virtru Developer Hub’s into my client-side HTML file to import the Virtru SDK and styling: browser JS quick-start < > head < = = /> link href "https://sdk.virtru.com/js/latest/auth-widget/index.css" rel "stylesheet" < = > script src "https://sdk.virtru.com/js/latest/auth-widget/index.js" </ > script < = > script src "https://sdk.virtru.com/js/latest/virtru-sdk.min.js" </ > script </ > head Above: virtruSidebar.html - Adding Virtru SDK & styling to client-side HTML. Next, I need to add the element that will actually perform the encryption step — the Virtru ‘client’. Again, the has some helpful code I can copy to generate the client: browser JS quick-start < > body < = > div id "virtru-auth-widget-mount" </ > div < = > script type "text/javascript" { client = Virtru.Client({email}); yourString = prompt( , ); encryptParams = Virtru.EncryptParamsBuilder()
        .withStringSource(yourString)
        .withDisplayFilename( )
        .build(); ct = client.encrypt(encryptParams); ct.toFile( );
    } Virtru.AuthWidget( , {afterAuth}); async ( ) function afterAuth email // Run all client code from here. // This will only be called when the user is successfully authenticated. const new const 'Type a sting to encrypt: ' 'Hello, world!' const new 'hello.txt' const await await 'hello.html' // Set up the auth widget. 'virtru-auth-widget-mount' </ > script </ > body Above: virtruSidebar.html - Loading default Virtru client. This is a good start, but as-is, this client is configured to accept a simple string input and output an encrypted .txt file; I need to take a PDF as input and output an encrypted PDF before this will actually be useful. Generating a PDF As noted above, most of what this add-on will do can be accomplished with the native tools available in Google Apps Script, including the generation of a PDF from Google Docs content. First, I’ll add some server-side code to generate a blob from the current document and format as a base-64 string for easy transport to the client: { docBlob = DocumentApp.getActiveDocument().getBlob();
  docBlob.setName(doc.getName() + ); blobB64 = Utilities.base64Encode(docBlob.getBytes()); blobB64;
} ( ) function createPDF var '.pdf' var return Above: Code.gs - Creating PDF blob from Google Doc content. And then a client-side function to call the above server-side function and return the document data to the client: { ( {
             google.script.run
               .withSuccessHandler( {
                 resolve(blobB64);
               })
               .createPDF();
           });
         } /*      
    * Runs server-side function to return the contents
    * of the document in base64 format.
    *
    * @return {string} Base 64'd document content.
    */ ( ) function genPDF return new Promise ( ) function resolve, reject ( ) function blobB64 Above: virtruSidebar.html - Calling the server-side function to generate pdf blob & transport to client. Customizing the Quick Start In order to encrypt a file rather than a simple text string, I’ll make two adjustments to the Virtru client: Change the data source for encryption from string to array buffer. With an array buffer input, the client can accept any file type so long as it has been .Change the output type to ensure the final encrypted file will render as and decrypt to PDF.virtruSidebar.html: Updating the client to accept arrayBuffer and output pdf.tdf3.html. appropriately converted beforehand { client = Virtru.Client({email}); yourString = prompt( , ); encryptParams = Virtru.EncryptParamsBuilder()
        .withArrayBufferSource(arrayBuffer) .withDisplayFilename( ) .build(); ct = client.encrypt(encryptParams); ct.toFile( ); } Virtru.AuthWidget( , {afterAuth}); async ( ) function afterAuth email // Run all client code from here. // This will only be called when the user is successfully authenticated. const new const 'Type a sting to encrypt: ' 'Hello, world!' const new // Change input to accept arrayBuffer 'hello.pdf' // Change display filename to reflect PDF const await await 'hello.pdf.tdf3.html' // Change output file extension to pdf.tdf3.html // Set up the auth widget. 'virtru-auth-widget-mount' Above: virtruSidebar.html - Updating the client to accept arrayBuffer and output pdf.tdf3.html. At this point, the add-on can generate an encrypted copy of the Google Doc. Great! However, it lacks any access controls or sharing options. By default, the document owner is the only authorized user. Let’s change that. Adding Access Controls Each data object protected by is associated with a that dictates the authorized recipients and access controls such as expiration date & watermarking. Based on the data owner’s inputs, I can construct a policy object to pass to the encryption client. In the example below, user input is captured by a series of checkbox elements, but you can use whatever mechanism you like: Virtru encryption policy { policy = Virtru.PolicyBuilder(); ($( ).is( )) {
             policy.enableWatermarking();
           } ($( ).is( )) {
             policy.disableReshare();    
           } ($( ).is( )) { ($( ).is( )) { expTime = ( * ); .log(expTime);
             } ($( ).is( )) { expTime = ( * * ); .log(expTime);
             } ($( ).is( )) { expTime = ( * * * ); .log(expTime);
             } ($( ).is( )) { expTime = ( * * * * ); .log(expTime);
             }
             policy.enableExpirationDeadlineFromNow([expTime]);
           } policy.build();
         } /*
    * Builds policy according to user inputs. 
    *
    * @param {Array}   authUsers  The list of authorized users for this piece of content.
    * @return {Policy}            The policy for this piece of content.
    */ ( ) function buildPolicy var new if '#watermark-toggle' ":checked" if '#disable-reshare-toggle' ":checked" if '#expiration-toggle' ":checked" if '#one-hour-expire' ":checked" var 60 60 // Expiration time is set in "seconds from now" console if '#one-day-expire' ":checked" var 60 60 24 console if '#one-week-expire' ":checked" var 60 60 24 7 console if '#one-month-expire' ":checked" var 60 60 24 7 4 console return Above: virtruSidebar.html - Creating an access control policy based on user input checkboxes. The policy is then passed to the encryption client. Authorized users can be included in the policy object itself, or added as an additional encryption parameter {array} as shown here: encryptParams = Virtru.EncryptParamsBuilder()
  .withArrayBufferSource(arrayBuffer)
  .withDisplayFilename( )
  .withPolicy(policy)
  .withUsersWithAccess(authorizedUsers)
  .build(); const new ` .pdf` ${docTitle} Above: virtruSidebar.html - Adding the policy object and authorized users to the encrypt client. Sending an Email If I want to email the encrypted file to the authorized users rather than download it, I need to change the code a bit. Instead of encrypting directly to a file, I’ll encrypt to a string. That string includes the encrypted file ciphertext and the HTML data that allows a user to open it in the browser: client = Virtru.Client({email}); encryptParams = Virtru.EncryptParamsBuilder()
             .withArrayBufferSource(arrayBuffer)
             .withDisplayFilename( )
             .withPolicy(policy)
             .withUsersWithAccess(authorizedUsers)
             .build(); ct = client.encrypt(encryptParams); ctString = ct.toString(); userMessage = $( ).val().replace( , ); google.script.run.sendEmail(ctString, authorizedUsers, userMessage); const new const new ` .pdf` ${docTitle} const await var await // Encrypt to string rather than to file // Run server-side function to generate an email // to the list of authorized users and include // the HTML generated above as an attachment. var '#email-body' /\n/g '<br/>' // Take user input from a field in the sidebar and preserve line breaks Above: virtruSidebar.html - Updating the client to send encrypted content server-side for email generation. This string can then be passed to a server-side function to create an email with the encrypted file attached: { fileOwner = Session.getActiveUser().getEmail(); fileName = DocumentApp.getActiveDocument().getName() + ; emailBody = fileOwner + + fileName + + ; htmlContent = HtmlService.createTemplateFromFile( );
  htmlContent.fileOwner = fileOwner;
  htmlContent.fileName = fileName;
  htmlContent.userMessage = userMessage; subject = fileOwner + + fileName + ; blob = Utilities.newBlob(cipherText, , fileName); MailApp.sendEmail(recipients, subject, emailBody, { : fileOwner, : [blob], : htmlContent.evaluate().getContent()
  });
} ( ) function sendEmail cipherText, recipients, userMessage // Get email address of file owner and assign attachment title. var var ".pdf.tdf3.html" // Provide a basic email body for recipients who do not support HTML. var " has shared the encrypted file " " with you.\r\n\r\nIt\'s attached below; please download to open in" " Virtru\'s Secure Reader." // Assign values to variables in emailHTML.html template. var 'emailHTML' // Create subject line based on filename and owner email address. var ' has shared a secure file: "' '"' // Convert ciphertext string to HTML blob. var 'text/html' // Send the email with the tdf.html blob as attachment. name attachments htmlBody Above: Code.gs - Server-side function to generate and send an email with encrypted attachment. Tying It All Together With all the components working as needed, the final step is to make this into something a human can actually use. I added some toggles, buttons, text input fields, and a little jQuery to allow users to perform the following actions: Choose “Encrypt & Download” or “Encrypt & Email”.Add authorized users.Add access controls.Include a custom message to email recipients. This actually accounted for the majority of code that I wrote for this project. The protection-specific pieces — encrypting the file and adding access controls — account for a very small portion of the add-on. And of that portion, I copied and pasted most of it! , where you can take a look at all the additional elements I added. Here’s the full add-on in action: The entire project is available on GitHub Encrypt & Download: Above: Encrypting, downloading, and previewing the document. Encrypt & Email: Above: Encrypting, emailing, and accessing the document. Food for Thought This ended up being easier to implement than I thought it would be. In fact, the steepest learning curve for me was figuring out where Google Apps Script and vanilla JavaScript differ and how they best interact. Adding encryption to the add-on was almost an afterthought. So while this project may not be directly applicable to you or your organization, it should illustrate how quickly you can integrate data protection into your own workflows. With this under my belt, I think I’ll try to develop some additional functions or new add-ons to see how else I can leverage Google Apps Script in my day-to-day. Please let me know in the comments if you have any ideas for next projects or additional features! About Me I’m a Solutions Engineer at Virtru, where I work with our customers to identify areas of their environments where additional data protections are needed, and develop solutions using Virtru’s Data Protection Platform & SDKs to meet those needs. Our developer platform is built on our SaaS Key and Policy Infrastructure to support data security using the open standard , audit, and control. TDF3

How to Share Google Docs Securely with a Google Apps Script

Scaling Bitcoin On-Chain with Omnity

Omnity সহ বিটকয়েন অন-চেইন স্কেলিং

Bitcoin On-Chain skalieren mit Omnity

Escalando Bitcoin On-Chain con Omnity

Faire évoluer Bitcoin en chaîne avec Omnity

ओम्निटी के साथ बिटकॉइन को ऑन-चेन स्केल करना

Omnity によるオンチェーンでのビットコインのスケーリング

Omnity로 비트코인 온체인 확장

Escalando Bitcoin On-Chain com Omnity

Масштабирование биткойнов в цепочке с помощью Omnity

Omnity ile Bitcoin'i Zincir Üzerinde Ölçeklendirmek

Mở rộng quy mô Bitcoin trên chuỗi với Omnity

使用 Omnity 在链上扩展比特币

How to Run Your Own Local LLMs: Updated for 2024 with 15 Local LLM Open Source Tools!

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

https://hackernoon.com/startups/country/asia-bengaluru-ka-india Tell us how your startup is changing the world. Zeliot isn't just another tech product; we're transforming the connected mobility landscape. Our mission is to empower partners with world-class, secure mobility solutions delivered through a highly scalable, deep-tech platform deployable on their cloud infrastructure. We envision a future where connected mobility is simple, secure, and accessible for everyone, with data control firmly in the hands of its rightful owners. Our flagship products, Condense and Condense Edge, are making this vision a reality. is a revolutionary, verticalized mobility cloud platform that deploys in just a few clicks on clients' existing infrastructure. It acts as a central hub, ingesting all mobility data from various sources and simplifying data management with a low-code interface. Condense empowers users to build customized mobility solutions based on their specific needs, unlocking the power of real-time data and actionable insights. With Condense, innovation knows no bounds. Condense complements this power with modular, low-memory footprint embedded firmware designed for vehicles. It seamlessly collects and transfers rich datasets from vehicles, enabling over-the-air (OTA) updates for vehicle ECUs. This valuable data fuels crucial insights, optimizes vehicle performance, enhances safety with daily safeguards, and drives cost savings and uptime. Condense Edge Our impact is real and growing. Industry leaders like Royal Enfield, Ashok Leyland, Volvo Trucks, TVS Motors, Bosch, and Here Maps, among many others, have already chosen Zeliot's platform to power their solutions. In 2022, Bosch further validated our vision by acquiring a 14% stake in the company. This is just the beginning – we're excited to continue empowering the connected mobility future, one secure, scalable, and accessible solution at a time. What sets you apart from the competition? The current connected mobility landscape faces two major issues: data security and lack of data ownership. Data often resides in solution provider clouds, creating concerns about confidentiality and potential misuse. Clients encounter various technical and commercial challenges, including: Complex cloud infrastructure: Building and maintaining cloud infrastructure is costly and resource-intensive. Disparate tools and technologies: Integrating multiple tools leads to disjointed workflows and data silos. Dedicated DevOps team: Running these systems requires specialized expertise, adding operational overhead. Huge data volumes: Managing massive data streams from diverse sources can be overwhelming. Lack of ROI: Demonstrating the return on investment for connected mobility solutions can be difficult. Data security and privacy: Data breaches and unauthorized access are major concerns. Limited customization: Generic solutions often fall short of specific needs. High initial investment: Costly upfront investments hinder adoption. Zeliot's Winning Propositions: Data Ownership & Security: Zeliot stands out by deploying our platform on the client's cloud infrastructure. This ensures complete data ownership and control. Neither Zeliot nor any third party can access client data, addressing security concerns and fostering trust. Scalability & Ease of Use: Condense is a mobility vertical cloud platform that scales seamlessly with your needs. It manages all required services for real-time data ingestion, eliminating the need for dedicated DevOps teams. With pre-built connectors and a low-code interface, Condense simplifies data management and analytics for all users. Edge Computing & Secure Updates: Condense Edge enables secure data transfer and device uptime assurance. Remote troubleshooting and updates are facilitated through bidirectional communication, removing the need for manual intervention. Our OTA campaign management ensures smooth and secure updates for your vehicles. Zeliot empowers clients with complete data ownership, secure solutions, and flexible tools to navigate the connected mobility landscape effectively. We go beyond standard offerings, addressing key client challenges and delivering tangible business value. What do you love about your team, and why are you the ones to solve this problem? At , the team isn't just a collection of individuals; it's a powerhouse driven by passion and expertise. What I love most is the infectious enthusiasm everyone brings to every challenge. We share a common vision of transforming connected mobility into a secure, accessible space, fueling our relentless pursuit of innovation. Zeliot Here's what makes us uniquely qualified to tackle the data ownership and security issues in connected mobility: Diverse & Experiential: Our team boasts backgrounds in embedded systems, cloud computing, data security, and automotive engineering. This synergy of knowledge allows us to approach problems from multiple angles and create holistic solutions. Proven Track Record: Many of our team members have extensive experience leading projects for major OEMs and enterprises. This translates into a deep understanding of their specific needs and pain points, enabling us to develop solutions that resonate deeply. Passionate Problem Solvers: We're not just skilled; we're obsessed with finding solutions. We thrive on tackling complex challenges and don't shy away from venturing into unexplored territory. This relentless curiosity fuels our innovation engine. Client-Centric Approach: Every decision we make starts with the client's needs in mind. We actively engage with them, understand their unique challenges, and tailor our solutions accordingly. This collaborative approach fosters trust and long-term partnerships. We possess the talent, experience, and unwavering passion to navigate the complexities of the connected mobility landscape. Our team is not just solving a problem; we're building a revolution. At the moment, how do you measure success? What are your core metrics? Success is gauged through the widespread adoption and endorsement of Zeliot's Platform by such as Royal Enfield, Ashok Leyland, Volvo, Eicher, Tata Motors, TVS Motors, Ampere, Bosch, Here Maps, and numerous others. This robust endorsement signifies the resonance of our solutions within the market and underscores their efficacy in addressing contemporary mobility challenges. industry leaders Furthermore, the strategic alliance with Bosch, evidenced by their acquisition of a 14% stake in Zeliot in 2022, serves as a pivotal milestone in our journey. It not only validates the viability of our vision but also strengthens our position as a frontrunner in the mobility solutions space. In essence, the metric of success is manifested through the growing roster of industry partners and stakeholders who entrust Zeliot. What goals are you looking forward to accomplishing in 2024? In 2024, Zeliot is driven by ambitious goals to further revolutionize the connected mobility landscape. Here are our key highlights: Breakthrough Edge-Based Analytics: Launch a revolutionary edge-based fuel analytics solution. This eliminates the need for external sensors, drastically reducing costs and streamlining data collection. Capture fuel events with 100% accuracy and real-time analysis. This enables precise fuel tracking and optimization, saving valuable resources and reducing emissions. Deliver high-frequency event alerts. By proactively identifying anomalies, operators can minimize downtime and prevent costly repairs. Secure Data Marketplace for Monetization: Onboard more OEMs and create a secure data marketplace. This empowers them to monetize their valuable data by sharing it with authorized stakeholders under agreed-upon terms. Unlock new revenue streams for OEMs and Enterprises. This fosters collaborations and expands the connected mobility ecosystem. Prioritize data security and privacy. Our marketplace leverages advanced security measures to ensure trusted data exchange and transparency. Which trend(s) are you most excited about in 2024? Share your reasons. The above-mentioned goals resonate with the immense potential of the connected mobility market. Industry analysts expect significant growth, with estimates suggesting the market will reach USD 20.5 billion by 2026 and USD 34.5 billion by 2030. This explosive growth signifies the increasing demand for innovative solutions that address data ownership, security, and cost-effectiveness. Zeliot is uniquely positioned to capitalize on these opportunities. Our cutting-edge technology, passionate team, and client-centric approach enable us to deliver solutions that exceed expectations. We believe that in 2024, Zeliot will not only achieve these goals but also establish itself as a leading force in shaping the future of secure and sustainable connected mobility. 2023 had been another crazy year, especially in tech, with layoffs and the Generative AI takeover! Which trend are you most concerned about? Be as brief or as detailed as you like. One concerning trend in the tech industry is the increasing frequency of data breaches in the mobility sector. As transportation becomes more digitized and reliant on interconnected systems, the potential for cyberattacks and data breaches rises significantly. These breaches not only compromise user privacy but also endanger public safety and trust in mobility services. Furthermore, the trend of valuation bubbles poses a significant risk to the stability of the tech industry. With skyrocketing valuations fueled by speculation rather than fundamental value, there's a real danger of a market correction that could lead to widespread layoffs, investor losses, and economic instability. Share your biggest success so far and/or your biggest failure so far. Zeliot's journey has been anything but linear; it's a captivating narrative of pivoting and seizing opportunities. Our greatest success story doesn't derive from a single product launch or milestone; rather, it emerges from a strategic reevaluation of vision and approach. Initially focused on fleet management solutions (FMS) as a Software as a Service (SaaS) offering, we provided customers with real-time asset visibility. However, the landscape of the Indian automotive industry soon underwent a significant shift: manufacturers began integrating telematics directly into vehicles. While some may have viewed this development as a setback, we saw it as a transformative moment. Rather than persisting in the crowded FMS market, we made the strategic decision to pivot towards a dedicated platform for connected mobility. This platform wasn't merely about providing generic solutions; it was designed to empower clients to develop custom, industry-specific applications. This bold maneuver, characterized by strategic foresight and adaptability, ultimately defined our success. This pivot opened doors we hadn't previously imagined. Major Original Equipment Manufacturers (OEMs) and large enterprises seeking specialized solutions turned to Zeliot. Our platform's flexibility and security resonated with them, enabling the creation of tailored applications that addressed their unique needs and unlocked distinct value propositions. In my view, Zeliot's greatest achievement isn't simply becoming the preferred platform; it's about evolving into a trusted partner. By empowering our clients to innovate and flourish in the realm of connected mobility, we're not only making headlines in the industry but also leaving an indelible mark on the very essence of connected mobility itself. We would love your feedback on HackerNoon as a tech publication! How has your experience been with us? As a fellow entrepreneur and tech enthusiast, I've enjoyed reading and engaging with HackerNoon. I appreciate the platform's commitment to diverse voices, thought-provoking content, and fostering a strong community. However, I believe there's room for improvement in a few key areas: Visibility and Reach: While HackerNoon offers valuable content, reaching a wider audience would benefit both readers and contributors. Increased marketing efforts, leveraging cross-platform promotion, and strategic partnerships could significantly impact readership and engagement. Overall, I've had a positive experience with HackerNoon, and I look forward to seeing how the publication continues to evolve and grow in the future. Any words of wisdom you’d like to share with us? In navigating the complexities of the tech industry and entrepreneurship, I'd emphasize the importance of staying true to your vision while remaining adaptable to change. Embrace challenges as opportunities for growth, and prioritize integrity, innovation, and customer-centricity in all your endeavors. Remember, success is not just about achieving milestones; it's about making a meaningful impact and leaving a positive legacy in the world. Keep learning, stay resilient, and never underestimate the power of collaboration and community in driving progress and innovation. Wishing you all the best on your journey of transformation and growth!

Meet Zeliot, Runner-up of the Startups of the Year in Bengaluru

100 Stories To Learn About Remote

CLIENT HUB SOLUTIONS

clienthub.app

-- employees

Since n.d.

COMPANY RANKING

CLIENT HUB SOLUTIONS

EVERGREEN INDEX #3212

Representing this company? Click here to claim and customize this page!

Client Hub Solutions WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

CLIENT HUB SOLUTIONS

clienthub.app

-- employees

Since n.d.

COMPANY RANKING

CLIENT HUB SOLUTIONS

EVERGREEN INDEX #3212

RELATED COMPANIESRANK

STORIES ABOUT CLIENT HUB SOLUTIONS

Representing this company? Click here to claim and customize this page!

Client Hub Solutions WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!